Core Data Ensembles
Ensembles extends Apple’s Core Data framework to add peer-to-peer synchronization for Mac OS and iOS. Multiple SQLite persistent stores can be coupled together via a file synchronization platform like iCloud or Dropbox. The framework can be readily extended to support any service capable of moving files between devices, including custom servers.
There doesn’t yet seem to be a detailed description of how it works. My impression is that it’s supposed to be the general Core Data iCloud approach, done right, and generalized to support other servers.
Update (2013-10-02): Drew McCormack:
In stark contrast to iCloud—Core Data, you also shouldn’t need to tear down your Core Data stack at any point just to accommodate Ensembles. Your
NSManagedObjectContextcan proceed unhindered, even when Ensembles has no connection to the cloud, or a catastrophic problem arises, such as the user changing cloud accounts. Syncing may terminate, but your app will go forth as though nothing happened.And when your app is ready to reconnect to the cloud, Ensembles automatically migrates data to the cloud, so again, you are not required to play musical chairs with store files, and artificial migrations between stores, like you must when using iCloud—Core Data synchronisation.
[…]
We are dealing with a decentralised, peer-to-peer synchronisation model, where no device can assume it has the complete global state at any point in time. When merging a change set from a different device, it is often necessary to reapply changes from a change set that has already been merged, in order to guarantee eventual consistency.
[…]
A temporary background
NSManagedObjectContextis created which shares the same SQLite store as the main context. Change sets are merged into this context, in order, with no regard to validity of the object graph. When it is time to commit the changes, a delegate method is invoked to give the host app an opportunity to apply any repairs that it wants to make before the data is sent to disk. A second delegate method is called if the background save fails, offering another opportunity to make repairs. Any repairs made by the application code are captured and added as a change set.(This whole process is very much analogous to how a developer uses a DVCS like Git. Typically, you pull new versions from a server, and merge them with your local changes. If conflicts arise, you repair them, and commit these new changes, before pushing all local changes back to the server.)
Sounds like a good start. Unlike iCloud, the persistent store is never in an invalid state. It doesn’t yet support large blobs or compacting change sets.
3 Comments RSS · Twitter
It looks interesting... And the details are **literally** gory, as there is some _leeching_ involved :-)
[…] Core Data story. As far as I know, there is still isn’t one. Meanwhile, Drew McCormack built the Ensembles framework, which fixes just about all the problems with Apple’s design and […]
