2

我正在使用 UIManagedDocument 和 ubiquity 选项（NSPersistentStoreUbiquitousContentNameKey 和 NSPersistentStoreUbiquitousContentURLKey）测试 Core Data 和 iCloud。一切正常。我的设备在合理的时间内毫无问题地同步。数据库很小（低于 100K）。

正如我所说，我正在测试应用程序并对数据库进行大量更改，结果生成了大量事务日志。我遇到的问题是，如果我在用于测试的其中一台设备上删除并重新安装该应用程序（不删除 iCloud 数据），该应用程序需要很长时间才能打开文档。openWithCompletionHandler 需要几分钟，有时永远不会结束。如果我打开调试（-com.apple.coredata.ubiquity.logLevel 3），我可以看到有很长的等待，然后用事务日志重建数据库。如果我删除 iCloud 数据并在第一台设备上重新插入数据，则第二台设备同步没有问题。因此，我认为延迟的原因是大量事务日志（测试时为 20-30，正如我在 developer.icloud.com 上看到的那样）根据管理核心数据 iCloud 事务日志将自动处理核心数据，但我看不到任何删除。也许这还需要一些时间。

我的问题是：事务日志是否得到整合？我可以强制合并日志吗？另一个推荐的选择？

我只将同步所需的基本信息子集存储在 iCloud Core Data 文件中。我有另一个包含完整数据库的本地文件，因此我可以重建 iCloud 数据库而不会丢失任何重大信息。当我检测到一堆日志并重新创建它时，也许我可以删除 iCloud DB。您认为这是一个不错的选择吗？

谢谢你的帮忙。

4

1 回答 1

2

事务日志是否得到整合？

这就是它应该如何工作的方式。

我可以强制合并日志吗？

不，没有直接影响事务日志存在的 API。iCloud 系统会在某个时候整合它们，但没有关于何时发生这种情况的文档，您无法强制执行。

另一个推荐的选择？

您可以间接限制事务日志的数量——减少保存更改的频率。事务日志对应于保存 Core Data 中的更改。这可能没什么区别，因为老实说，20-30 个事务日志并不是很多。您也许可以减少日志文件的数量，但其中的数据量仍然相同。

事务日志并不是你真正的问题。正如您所观察到的，在 iCloud 开始运行事务日志之前需要等待很长时间。在此延迟期间，iCloud 正在与 Apple 的服务器通信并下载交易日志。其中一些受网络速度和延迟的影响，其余的只是 iCloud 的方式。

于 2013-02-24T22:25:14.947 回答