评估使用Dropbox同步核心数据的策略

Question

这个问题是关于使用Dropbox在多个iOS设备之间同步sqlite Core Data存储.考虑这种安排:

1. 应用程序使用Core Data存储,调用它local.sql,保存在应用程序自己的存储中NSDocumentDirectory

2. 该应用程序使用Dropbox Sync API观察用户Dropbox中的某个文件,例如, user/myapp/synced.sql

3. 应用程序观察NSManagedObjectContextDidSaveNotification,并在每次保存时复制local.sql到user/myapp/synced.sql,从而替换后者.

4. 当Dropbox的API通知我们synced.sql改变,我们做的第3部分或多或少相反:推倒核心数据堆栈,更换local.sql用synced.sql,并重新创建核心数据堆栈.用户同时在UI中看到"同步"或"正在加载".

问题:

A.这种安排是否非常低效,应该完全避免？如果我们能保证数据库的规模不大,该怎么办？

B.这种安排是否有利于文件腐败？通过增量/更改日志进行同步？如果是这样,请您详细说明原因？

Answer 1

A.这种安排是否非常低效,应该完全避免？如果我们能保证数据库的规模不大,该怎么办？

不相关,因为:

B.这种安排是否有利于文件腐败？通过增量/更改日志进行同步？如果是这样,请您详细说明原因？

是的,非常如此.几乎可以保证.我建议查看如何破坏SQLite数据库文件.另外,您可能至少犯下第1部分中描述的两个问题,包括在事务处于活动状态时复制文件以及删除(或无法复制或制作无用的副本)日志文件.在任何严肃的测试中,您的计划几乎可能立即崩溃.

如果这还不够糟糕,请考虑两台设备同时保存更改的情况.然后怎样呢？如果你很幸运,你只会得到一个Dropbox臭名昭着的"冲突副本"文件副本,"仅"意味着丢失一些数据.如果没有,您再次陷入完全数据库损坏.

当然,拆除核心数据堆栈以进行同步对用户来说是一个巨大的不便.

如果您想考虑通过Dropbox同步Core Data,我建议使用以下方法之一:

1. 合奏,可以通过Dropbox同步(同时避免上述问题)或iCloud(同时避免iOS内置Core Data/iCloud同步的问题).
2. TICoreDataSync,它使用Dropbox文件同步但避免将SQLite文件放在文件存储中.
3. ParcelKit,它使用Dropbox的新数据存储API.(请注意,这是一个非常新的,数据存储API本身仍然是测试版).