评估与Dropbox同步核心数据的策略 [英] Evaluation of a strategy to sync Core Data with Dropbox
问题描述
这个问题是关于使用Dropbox在多个iOS设备之间同步sqlite Core Data存储。考虑这种安排：
This question is about using Dropbox to sync an sqlite Core Data store between multiple iOS devices. Consider this arrangement:
-
应用程序使用Core Data存储，调用
local.sql，保存在应用程式自己的NSDocumentDirectory
应用程式使用Dropbox Sync API观察用户Dropbox中的某个文件，例如 user / myapp / synced.sql
The app uses the Dropbox Sync API to observe a certain file in the user's Dropbox, say, user/myapp/synced.sql
应用程序观察 NSManagedObjectContextDidSaveNotification ，并在每次保存时将 local.sql 复制到 user / myapp
The app observes NSManagedObjectContextDidSaveNotification, and on every save it copies local.sql to user/myapp/synced.sql, thereby replacing the latter.
当Dropbox API通知我们已同步时。 sql 更改，我们做或多或少相反的第3部分：拆卸核心数据堆栈，替换 local.sql 与 synced.sql ，然后重新创建Core Data堆栈。
When the Dropbox API notifies us that synced.sql changed, we do the opposite of part 3 more or less: tear down the Core Data stack, replace local.sql with synced.sql, and recreate the Core Data stack. The user sees "Syncing" or "Loading" in the UI in the meantime.
问题：
A。这种安排是否非常低效，应该完全避免？如果我们能保证数据库的大小不大怎么办？
A. Is this arrangement hugely inefficient, to the extent where it should be completely avoided? What if we can guarantee the database is not large in size?
B。这种安排是否有助于文件损坏？超过同步通过deltas / changelogs？如果是，请您详细解释为什么？
B. Is this arrangement conducive to file corruption? More than syncing via deltas/changelogs? If so, will you please explain in detail why?
推荐答案
这种安排是否非常低效，应该完全避免？
A. Is this arrangement hugely inefficient, to the extent where it should be completely avoided? What if we can guarantee the database is not large in size?
不相关，因为：
B。这种安排是否有助于文件损坏？超过同步通过deltas / changelogs？如果是，请您详细解释为什么？
B. Is this arrangement conducive to file corruption? More than syncing via deltas/changelogs? If so, will you please explain in detail why?
是的，非常非常。几乎保证。我建议您查看如何破坏SQLite数据库文件。你可能会提交第1节中描述的至少两个问题，包括在事务处于活动状态时复制文件，并删除（或无法复制或无用的副本）日志文件。在任何严重的测试中，您的方案很可能立即崩溃。
Yes, very much so. Virtually guaranteed. I suggest reviewing How to Corrupt An SQLite Database File. Offhand you're likely to commit at least two of the problems described in section 1, including copying the file while a transaction is active and deleting (or failing to copy, or making a useless copy of) the journal file(s). In any serious testing, your scheme is likely to fall apart almost immediately.
如果这还不够，请考虑两个设备同时保存更改的情况。然后怎样呢？如果你幸运，你只会得到一个Dropbox的臭名昭着的冲突的副本的文件的副本，只意味着丢失一些数据。
If that's not bad enough, consider the scenario where two devices save changes simultaneously. What then? If you're lucky you'll just get one of Dropbox's notorious "conflicted copy" duplicates of the file, which "only" means losing some data. If not, you're into full database corruption again.
当然，拆除Core Data栈以进行同步对用户来说是一个巨大的不便。
And of course, tearing down the Core Data stack to sync is an enormous inconvenience to the user.
如果您想考虑通过Dropbox同步Core Data，我建议使用以下方法之一：
If you'd like to consider syncing Core Data via Dropbox I suggest one of the following:
- Ensembles ，可以同步Dropbox（同时避免上述问题）或iCloud（同时避免问题iOS内置的Core Data / iCloud同步）。
- TICoreDataSync ，它使用Dropbox文件同步，但避免在文件存储中放置SQLite文件。
- ParcelKit ，它使用Dropbox的新数据存储API。 （请注意，这是相当新的，数据存储API本身仍然是测试版）。
- Ensembles, which can sync over Dropbox (while avoiding the problems described above) or iCloud (while avoiding the problems of iOS's built-in Core Data/iCloud sync).
- TICoreDataSync, which uses Dropbox file sync but which avoids putting a SQLite file in the file store.
- ParcelKit, which uses Dropbox's new data store API. (Note that this is quite new and that the data store API itself is still beta).
这篇关于评估与Dropbox同步核心数据的策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
