ios - 从CloudKit删除记录时如何防止孤儿？

Question

CloudKit WWDC视频建议像这样实现同步:

跟踪本地更改

将更改发送到服务器

解决冲突

使用CKFetchRecordChangesOperation来获取服务器更改

应用服务器更改

保存服务器更改 token

我在我的应用程序中遵循了这种模式，但是我遇到了删除和父子关系的问题。

假设我们有一个分为几类的书籍清单。每本书必须完全属于一个类别。

我从这样的数据开始:

SERVER
Thrillers: "Look Out!", "Secret Spy"
Non-Fiction: "Sailing the Seas", "Gardening Adventures"
Computer Programming: <empty>

如您所见，最终类别为空。假设我有两个具有此数据精确副本的设备。

现在，在设备1上，用户将一本书 CloudKit Sync添加到“计算机编程”中:

DEVICE 1
Thrillers: "Look Out!", "Secret Spy"
Non-Fiction: "Sailing the Seas", "Gardening Adventures"
Computer Programming: "CloudKit Sync"

但是在设备2上，用户完全删除了“计算机编程”类别(该类别为空，因此从设备2的角度来看是可以的):

DEVICE 2
Thrillers: "Look Out!", "Secret Spy"
Non-Fiction: "Sailing the Seas", "Gardening Adventures"

设备1首先进行同步，因此它将创建一个新的 Book条目，其 parent字段设置为 Computer Programming。

但是现在设备2开始其同步过程。它将更改应用于服务器，因此删除了与“计算机编程”相对应的 CKRecord。这与设备2的世界观一致，在世界观中类别为空，可以删除。

但是，当它从服务器删除此类别时，就设备1的世界观和服务器本身而言，这没有任何意义。现在有一本名为 CloudKit Sync的孤儿书，它有指向父级的悬挂指针。

如果我遵循WWDC的Apple建议，如何避免这种情况？根据同步的顺序，我可以很容易地得到一本孤立的书和一个无效的父母参考的不一致状态。

我想要发生的是从设备2发出的 Delete命令返回一个错误，告诉我我要孤立一本书并完全阻止该操作发生，因此我可以采取一些措施来解决这种情况。

那可能吗？还有另一种方法可以解决这个问题吗？

Answer 1

是的，您想要的设备2行为是可能的。我看到了在您的方案中将要使用的cloudkit的三个方面。让我们先看看这些，然后再看它们在您的场景中的用法。

首先，假设两个(或所有)设备都已订阅对适当记录的更改，则将通知每个设备有人添加或删除了某些内容。然后，接收到警报的设备将有机会决定如何处理它。 (从本地视图中删除它，在服务器上替换它，等等)

其次，您可以使用savePolicy上的CKModifyRecordOperation设置处理冲突的行为。您可以指定最后的更改是否应该覆盖较旧的记录，引发错误等。有关这三个选项，请参见https://developer.apple.com/documentation/cloudkit/ckrecordsavepolicy?language=objc。 (我仅在两个用户修改一条 public 记录的上下文中使用过此方法，但是在另一位用户更新该记录后删除该文件将引发server record changed错误)。

第三，假设您已经配置了上述的savePolicy，那么服务器更改 token 本身就是。我发现最容易将更改 token 设想为最后修改的时间戳。 “这种记录的我的副本最近一次修改是在晚上10:42”。根据您在上述savePolicy中选择的覆盖选项，设备将收到NSError Server Record Changed，以警告您服务器上的版本来自晚上10:56，并且您的本地版本可能不再有效。

产生的NSError中的userInfo包含有问题的记录的3个版本:服务器上的当前版本，您尝试提交的版本以及 public 祖先版本。苹果公司的指南说，由开发人员决定如何合并这些信息。但从理论上讲，您将能够区分更改，确定要保留的内容，然后提交新操作。

关于您的特定情况:假设您完全授权并信任dev1和dev2删除记录，那么我将订阅创建和删除事件，并设置savePolicy在尝试发生冲突的更改时引发错误。在这种情况下，设备1将添加记录，而设备2将接收新记录的通知。如果设备2只是尝试删除旧记录，则它应失败并显示server record changed错误，您可以向用户显示为

“其他人修改了此记录，您真的要删除它吗？
(是/否)。”

在继续操作之前，设备2必须刷新记录(并接收新的记录更改 token )。此后，如果设备2仍要删除新记录，可以删除，但随后将通过上述订阅将更改通知给设备1。然后，设备1将新记录下载到其本地视图中(或在这种情况下，从中删除旧记录)。订阅通知可能会警告用户1:

“您的记录Foo被Bar删除了”

即使事件实际上是同时发生的，这也将起作用，因为其中一个更改将首先应用于服务器，而另一设备的 token 将立即过时。因此，如果设备2首先设法删除了记录，则设备1修改记录的尝试将失败，并带有server record changed，因为设备1的更改 token 现在已过期。设备1的错误处理程序将必须根据您的业务规则决定是接受删除还是继续创建新记录。也许向用户1询问类似以下内容:

从服务器上删除了“计算机编程”。您想重新创建吗
它？

此时，user1可以发送紧急电子邮件，要求其他用户停止删除其新创建的记录，而user2可以要求人们停止重新创建刚刚“清理”的记录。 :)

您可能会变得更加复杂，可能会给设备1优先于设备2的优先级，这样，当通知设备1记录已删除时，设备1会将记录重新写入服务器。如果您有多个具有删除权限的用户，则可以确定优先顺序并构建适当的错误/通知处理程序。但是，这似乎非常复杂且容易出错。可能会发生自动响应的循环(创建，删除，创建，删除，创建，删除)。我仅将其作为假设示例，而不作为建议!

最后，作为另一个示例，我的应用程序具有不同的方案。我的记录是游戏 session 。所有播放器都需要对 session 数据进行读取访问，但是只有始发者才可以选择完全删除记录。因此，您可能会考虑是否确实授权多个用户删除共享记录。