管理Core Data iCloud事务日志 [英] Managing Core Data iCloud Transaction Logs

问题描述

我使用iCloud与Core Data，基于Apple指定的SQLite库风格应用程序设计。虽然基本功能运作得很好，但我关心的是事务日志以及它们的管理方式。

I am using iCloud with Core Data, based on the SQLite "Library-style" application design as specified by Apple. While the basic functionality works very well, I am concerned about the transaction logs and how they are managed.

虽然我的应用程序的数据库不大，但它非常活跃并且当应用程序在使用时，核心数据堆栈被保存多次。我注意到，为每个核心数据保存创建一个新的事务日志。最终结果是我有一个TON的事务日志，并且他们占用比实际数据库更多的空间。

While the database for my app is not large, it is very active and the core data stack is saved many times while the app is in use. I have noticed that a new transaction log is created for every core data save. The end result is that I have a TON of transaction logs and they take up much more space than the actual database.

1）使事务日志自动修剪/合并，还是会继续无限增长，最终数以千计，并占用许多兆字节？似乎手动清除事务日志并重新创建.baseline存档的唯一方法是禁用并重新启用iCloud（删除无处不在的容器并重新启动）。但这显然不是一个好的解决方案。

1) Do the transaction logs ever get automatically pruned / coalesced, or will they continue to grow indefinitely, eventually numbering in the thousands and taking up many megabytes? It seems that the only way to manually purge the transaction logs and recreate a .baseline archive would be to disable and then re-enable iCloud (removing the ubiquity container and starting fresh). But this is obviously not a good solution.

2）我的当前架构经常保存核心数据堆栈，即使是微小的更改。一般来说，这是有道理的，因为我的数据库很小，保存经常保证数据库文件总是最新的。然而，鉴于上述事务日志的问题，我认为我应该尽量减少对数据库的保存。也许这样做的时间和/或应用程序的过渡状态。

2) My current architecture saves the core data stack often, even for minor changes. In general, this makes sense as my database is small and saving often ensures that the database file is always up-to-date. However, given the above issues with transaction logs, I am thinking that I should perhaps minimize saves to the database. Maybe doing so on a timed basis and/or on app transition states.

3）即使我通过减少我保存数据库的频率最小化事务日志的数量，这里似乎有一个问题，因为日志会随着时间的推移而持续增长。最终，事务日志设计的好处将成为使用的iCloud存储量和作为新设备添加的初始iCloud同步的负担。

3) Even if I minimize the number of transaction logs by reducing how often I save the database, there seems to be an issue here, as the logs will continue to grow in number over time. Eventually the benefit of the "transaction log" design will become a burden in terms of the amount of iCloud storage used and the initial iCloud sync as a new device is added.

由于苹果在iCloud上提供了非常稀疏的信息，几乎没有以最佳实践的形式提供。我非常感谢社区的任何见解。

As Apple has provided very sparse information on iCloud and almost nothing in the form of "best practices", I would appreciate any insight from the community.

推荐答案

我对此问题提出了雷达，并收到以下回复。他们注意到它应该在iOS 5.1中正常工作，虽然我还没有自己验证。

I filed a radar on this issue and received the following reply. They noted that it should be working correctly in iOS 5.1, though I have not yet verified this myself.

任何可能误会以下的人的说明。事务日志将由核心数据内部清理。这不是应用程序本身应该执行的操作。

A clarification for any who might misunderstand the following. The transaction logs will be cleaned up by the core data internals. This is NOT something that should be performed by the application itself.

工程提供了有关此问题的以下反馈：

Engineering has provided the following feedback regarding this issue:

事务日志将在所有活动的
对等体有机会读取它们后被删除，并且超过
空间消耗的阈值。有一个先前的问题阻止设备
正确地这样做。

The transaction logs are intended to be deleted after all the active peers have had a chance to read them, and they exceed a threshold of space consumed. There was a previous issue that prevented the devices from correctly doing so.

这篇关于管理Core Data iCloud事务日志的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！