Hacker News Reader

Comment by newhouseb | Hacker News Reader

Woah, who knew NSIncrementalStore has been exactly what so many of us have been looking for. After a quick scan through, this looks like it completely replaces, not wraps, the default SQLLite store, yes? In other words, if the network is down, you can't save anything that would be synched later or request any queries that weren't cached? Or maybe I'm just not reading things right.

Full offline functionality is pretty important to us so I wonder if there is a nice way to make the NSIncrementalStore wrap a regular old SQLLite CoreData store and fault out to the network if something isn't found locally and conversely, store any new calls that need to be made until network is available.

View on HN

In addition to AFIncrementalStore and the other suggestions in this thread, you should check out Simperium (http://simperium.com). Our iOS/OSX library watches your existing Core Data context and handles syncing transparently, with full support for offline use. Unlike other solutions, we use persistent connections and operational transforms to send only the data that changes, allowing many conflicts to be resolved automatically.

We've already been down the path of using a more traditional RESTful approach to syncing data with earlier versions of our app Simplenote. I agree it seems like it should be easy to just cache some offline data locally and send it up to a server at first opportunity. And you can write a prototype of that system pretty quickly. But in our experience at least, conflicts, errors, duplicates, etc. arise a lot more often than you might think and it's very hard to make a system like that reliable, not to mention scaling and maintaining it.

Hi Mike, I went to your talk at CocoaHeads a month or so ago - I'm a big fan.

Correct me if I'm wrong, but, a big part of the point of NSIncrementalStore is that you don't need the entire database locally to perform queries against it (hence, Incremental and not Atomic). If somebody wanted to go parading around someone else's data (imagine clicking around through a bunch of YouTube videos) that would require interfacing with Simperium's query API's on other people's buckets, and then maybe saving that to your own local CoreData store, right? As I understand it Simperium hooks into context change notifications to figure out locally performed OT and then periodically pulls from the network to find OT on the bucket performed elsewhere. Maybe a good next step for you guys would be to build in a NSIncrementalStore for querying outside of the synchronized bucket to other people's stuff.

Oh, hey!

Your analysis is accurate. Actually, one of the features we're preparing to launch is sharing/collaboration/groups, which will allow data in Simperium to flow across users the same way it currently flows across devices. But you're right in that having more ways to perform queries outside of a known data set would be useful too.

RestKit (http://restkit.org/) is working on something similar. Right now you have to manually push your data back to the REST service, but in version 0.11.0, they are going to add exactly the kind of functionality you're looking for:

https://github.com/RestKit/RestKit/pull/573

Yeah, we've written our own REST framework also which is actually surprisingly similar (and small, ~1k lines) to AFIncrementalStore which does all the things I mentioned except in a leakier abstraction completely outside of the CoreData store. It works well, but it pains me that there isn't a cleaner way.

I have a theory that this could be accomplished in the NSPersistentStoreCoordinator by setting up sister contexts--one for network, one for SQLLite. Network is the master, and replicates to SQLite, which could be used for reads if the network is slow or down.

Yeah, that sounds like a fair strategy, except that lots of nice things using KVO are now really hard because if you go online/offline you would be switching between different NSManagedObjects in different contexts. (In practice, we rarely use NSFetchRequests because our usage patterns fit well into the object graph, thus we use lots of KVO).

The two solutions would be A) make a NSManagedObject proxy class that actually proxies between the two NSManagedObject instances in different contexts (and maybe handle the replication here as well), or B) use two different NSPersistantStores in one context - but I cannot, for the life of me figure out how CoreData resolves conflicts between different Stores (network and sqlite) in the same Coordinator (NSMergeConflict doesn't seem to discuss this case).

Does anyone have experience using multiple stores and actually understand how NSPersistentStoreCoordinator handles conflicts?

Reply on news.ycombinator.com