如何解决为什么在 CloudKit 中使用 Core Data 时关系必须是可选的？ 编辑：
以下是在 Apple 的 doc 中将 Core Data 与 Cloudkit 配合使用的要求之一：
所有关系都必须是可选的。由于操作规模的限制， 关系更改可能无法自动保存。
我想知道，这不是完全违背了使用关系的目的吗？
例如，假设我有两个实体：Account 和 Transfer。由于转移始终与源帐户和目标帐户相关联，因此 Transfer 应该与 Account 有两个非可选关系。但是由于上述要求，这些关系必须可选。
文档给出了解释：“（这是因为）关系更改可能无法自动保存”。这似乎表明，在 Cloudkit 和 Core Data 之间的同步过程中，关系可能是不完整的并且不完整的关系会暴露给应用程序代码。这对我来说似乎是一个严重的问题，因为：
-
在我上面的例子中，这两种关系本质上是非可选的。将它们更改为 optional 会使模态变得毫无意义。
-
即使在那些关系应该是可选的示例中，虽然不完整的关系在语法上是正确的，但它可能会导致意外的不一致问题。
所以我想知道这应该如何在实际应用中工作？对我来说似乎很破碎。我误解了什么吗？ 会不会是使用 Cloudkit 同步 Core Data 只适用于一小部分只使用可选关系的应用？（如果是这样，我想知道其他 Core Data 应用是如何在设备之间同步数据的。 )
在相关说明中：像许多其他人一样，我努力搜索有关 Cloudkit 和 Core Data 使用的同步和冲突解决算法的详细信息。我能找到的仅有的一些信息是：
在最终一致的分布式系统中，您永远无法“知道” 您在云中拥有现有数据或设备。你的申请 将简单地“在某个时候发现”这些数据存在并且需要 旨在处理这个问题
是的，Core Data CloudKit 使用 CRDT 实现了多对多关系！
冲突解决由自动执行 NSPersistentCloudKitContainer 使用最后一个写入器赢得合并策略。
虽然我大致了解了这些信息中的每一条，但他们并没有给出关于 1) Cloudkit 和 Core Data 之间的数据更改是否以原子方式同步的直接结论？更重要的是 2) 同步期间是否会将不完整的数据暴露给应用代码？
我的猜测是 1) 否和 2) 是。但是如果在同步期间不完整的数据更改暴露给应用程序代码，我很难理解如何编写真正的应用程序。 难道是说，要使用 Cloudkit 同步 Core Data，必须将模态设计为在不完整关系下正常工作？
如果有人能分享您对它的理解，我将不胜感激。
解决方法
我想得越多，我就越相信：
-
数据更改以非原子方式在 Cloudkit 和 Core Data 之间同步。
-
数据同步期间不完整的状态会暴露给应用代码。
-
这些行为是由于同步的执行方式造成的，很难解决。
因此，Cloudkit 对 Core Data 的内置同步支持仅适用于一小组不需要数据完整性的简单应用程序。
对于严肃的应用程序，需要考虑通过直接使用 Cloudkit 来实现自定义方法。但是编写自己的同步算法并不是一件容易的事，而且充满了陷阱。
,我也为此苦苦挣扎，并提出了一些解决方案。
- 不要使用关系并使模型保持浅层（不理想或可扩展）
出于显而易见的原因，这不是理想的或可扩展的，但在我的一个应用程序中，我将 PKDrawing 数据直接存储在具有其他绘图相关内容的事件实体上，而不是使用关系。不过，这确实是在与 CoreData 框架作斗争，而且是糟糕的设计。
- 在获取期间检查关系是否存在。
这可能是用户创建数据的最佳解决方案。假设您有一个带有一对一画布的 Sketch。 在获取要在列表中显示的草图时，仅获取具有非零画布关系的草图。
Example of checking relationship
- 提供默认值
这适用于非用户创建的内容。例如在上面的示例中，Canvas 也可以与 PaperTemplate 具有一对一的关系。 PaperTemplate 存储诸如 PaperStyle (grid,lined) 之类的东西。由于可以在 PaperSettingsView 中轻松重新创建此数据（通过选择器），如果关系为零，我们可以简单地将 awakeFromFetch 中的默认值恢复为默认值。注意：我不确定，但这可能会导致 PaperTemplate 实体孤立。
最终我认为解决方案#2 是最好的全方位解决方案。如果我们只获取具有非 nil 关系的对象，我们可以确保模型是正确的。因此，您只能使用非零源帐户和目标帐户获取转移。如果这是使用 NSFetchedResultsController 或 SwiftUI @FetchRequest 完成的，则您的视图可以在对象变为“有效”时保持同步。虽然保存可能不是原子的，但客户端可以通过忽略不完整的对象来决定如何使用更改并模仿原子性。
编辑：
虽然我认为这样做是在对抗 Core Data。您可以使用手动编码/解码的 Transformable 或 Codable 结构来存储 blob。确保选中“允许外部存储”。
所以你可以使用：
class Transfer: NSManagedObject {
var sourceAccountData: Data?
var destinationAccountData: Data?
}
// Could use class and NSSecureCoding instead if you wanted,but I like structs.
struct Account: Codable {
}
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。