pipe理核心数据iCloud事务日志
我正在使用iCloud和Core Data，基于Apple指定的SQLite“Library-style”应用程序devise。 虽然基本function运行得很好，但是我担心事务日志以及它们的pipe理方式。
虽然我的应用程序的数据库不是很大，但它是非常活跃的，核心数据堆栈在应用程序正在使用时被保存很多次。 我注意到， 每个核心数据保存都会创build一个新的事务日志。 最终的结果是我有一个TON的事务日志，他们占用比实际的数据库更多的空间。
1）事务日志是否被自动修剪/合并，还是会继续无限增长，最终以千位计数，并占用数兆字节？ 似乎手动清除事务日志和重新创build.baseline归档文件的唯一方法是禁用然后重新启用iCloud（删除无处不在的容器并重新启动）。 但是，这显然不是一个好的解决scheme。
2）我目前的架构经常保存核心数据栈，即使是微小的变化。 一般来说，这是有道理的，因为我的数据库是小的，保存经常确保数据库文件始终是最新的。 但是，考虑到上述与事务日志有关的问题，我想我应该尽量减less对数据库的保存。 也许在定时和/或应用程序转换状态下这样做。
3）即使我通过减less保存数据库的频率来最小化事务日志的数量，这里似乎也存在一个问题，因为日志会随着时间的推移而继续增长。 最终，“事务日志”devise的好处将成为所使用的iCloud存储量的一个负担，并添加了作为新设备的初始iCloud同步。
由于苹果已经提供了关于iCloud的非常稀less的信息，而且几乎没有任何“最佳实践”的forms，所以我希望能够从社区获得任何见解。
我在这个问题上提出了一个雷达，并收到了以下答复。 他们指出，它应该在iOS 5.1中正常工作，尽pipe我自己还没有对此进行validation。
澄清任何人可能会误解以下内容。 事务日志将由核心数据内部清除。 这不应该由应用程序本身执行。
工程部门就这个问题提供了以下反馈意见：
在所有活动节点都有机会读取事务日志后，事务日志将被删除，并且超过了空间消耗的阈值。 之前的问题阻止了设备的正确操作。