Thanks again, Jens, for the lengthy and thoughtful response. I’ve been looking at Couchbase for a couple of years now (wasn’t it initially called Couchbase Mobile?), and I’ve used Blip in the past. Great stuff.
I read through some of the Couchbase Lite conceptual documentation. Since we’ve been focusing on conflict resolution, I was particularly interested in that section. Couchbase Lite’s conceptual documentation regarding Conflict Resolution and Revisions doesn’t, at first glance (and after a glass of wine — it’s okay, I’m on the East Coast, where it’s after 7pm), appear to be all that different from NSIncrementalStore’s. From Apple’s NSIncrementalStore Programming Guide: Best Practices: Optimistic Locking Optimistic locking is a mechanism in Core Data that gives the persistent store coordinator the ability to detect when in-memory conflicts occur and also handle when your incremental store detects that another client has made changes the backing store; Core Data manages multiple in-memory snapshots of your data, holding each snapshot inside a managed object context. When you insert, update, or delete managed objects in one context, that change is not reflected in other contexts. This allows you to do work on multiple contexts in different threads simultaneously without worrying about merge conflicts. Merging is deferred until the contexts are saved to the store. At that point, the merge policy you specify is applied by the persistent store coordinator. To facilitate the persistent store coordinator’s in-memory locking mechanism, your store should store a version number for each record in the backing store and increment it every time that record is saved. Detecting conflicts in the backing store is the responsibility of your custom incremental store. A conflict in the backing data store happens when records in the backing data store are changed by another persistent store coordinator or another client. For example, a client could fetch data from a web service and modify it. In the meantime, another client could fetch data from the web service, modify the records, and save. When the first client goes to save, your incremental store compares the optimistic locking version number of the incremental store node and the version number in the backing store and reports the conflict to the persistent store coordinator. The coordinator detects a merge conflict, and applies your merge policy. Optimistic locking failures are encountered when processing a save request inside executeRequest:withContext:error:. To report an optimistic locking failure in the backing data store, constructNSMergeConflict objects for each conflicting object in the save request, set the error parameter, and return nil from the method. You should not attempt to partially fulfill the save request. See theNSMergeConflict Class Reference for more information. The sections that follow I think are also applicable to the conversation: Working with Web Services When you create an incremental store that interfaces with a web service, you must take into account several unique factors: latency, network availability, and conflict management. Use your app requirements, use cases, and the Instruments app to choose what matters most and then profile until your store meets your needs. Threading When fetch and save requests are executed by managed object contexts on different threads, the persistent store coordinator collects the requests into a serial queue and dispatches each request to a single instance of your incremental store in the order in which they were received. Because the persistent store coordinator requires that results be returned immediately (rather than by a deferred callback mechanism), your store must synchronously return data from the backing data store. If your backing data store supports concurrent read and/or write operations, for optimal performance consider using multiple persistent store coordinators when designing your Core Data stack. NextPrevious On Oct 17, 2013, at 4:35 PM, Jens Alfke <j...@mooseyard.com> wrote: > > On Oct 17, 2013, at 11:05 AM, Brad Gibbs <bradgi...@mac.com> wrote: > >> Regarding your point about Core Data not being atomic: >> 1. It sounds like a perfectly reasonable and valid argument, but, then, why >> would Apple release NSIncrementalStore at all? What purpose would it serve? > > It would work well for other _local_ data stores. For example, we’re > considering making an NSIncrementalStore adapter for Couchbase Lite, because > the programming model for Couchbase Lite is that you work with a local > database, which gets synced with a server behind the scenes. > > Another possibility is if you want to persist to a static file, kind of like > the built-in XML store, but maybe with JSON. > > It could also work well in some kind of constrained network environment, like > running on a desktop computer with the server nearby on a LAN. > > It’s also possible that the people who work on Core Data are smart engineers > but not skilled enough at distributed programming to realize that their API > isn’t suitable for that task. The stuff Flavio quotes from the Apple docs > would kind of imply this. So would the whole debacle with iCloud Core Data > support. > >> It’s possible that one of the other two users with write access could be >> making changes to one of those five fields at the same time. If this >> happens, whichever save operation happens last wins and this could produce >> some undesirable consequences if the person who posted the second commit >> entered incorrect information. BUT, unless both users confirm their changes >> at precisely the same moment, isn’t it more-or-less equivalent to two >> transactions where the last one in wins? In other words, if the app is >> written such that users are forced to commit changes frequently enough, >> doesn’t it at some point become a transaction? > > Increments are a classic counterexample to this. If I click the “+1” button > on a project to increment its VoteCount field, and you do the same, the end > result is it got incremented once, while it really should have been > incremented twice. (The classic horror stories involve this happening with > deposits in a banking system.) > > It starts to get really bad when multiple docs are updated. For example, say > one user creates a new Phase in a Project while another user deletes the > Project. The end result is a Phase that points to a nonexistent Project. > Oops, database schema corruption. > >> I can definitely see how this lack of atomicity could cause serious problems >> if you’ve got 10,000 users with edit permissions and users can make several >> changes to several objects before committing, but, in this particular use >> case, maybe it isn’t a big enough issue to throw the baby out with the >> bathwater? > > It just depends on how often you’re comfortable with bad stuff like the above > happening. :) > >> What better options should I look at, instead? My company is three >> employees strong at the moment and we’re never going to be on the same LAN. >> I’ve looked at CouchBase, but I’m not sure NoSQL is the right fit. > > I’m going to recommend Couchbase Lite, because I think it’s a great solution, > not just because they pay me. The programming model is somewhere in between > Core Data and property lists — that is, a database is fundamentally a bag of > named dictionaries (i.e. JSON objects), but there’s a Model class that acts > like NSManagedObject to let you treat these as Obj-C objects with native > properties. > > On the plus side, you don’t have to worry about predefined schemas and > migrations, because you can add properties at any time. > On the down side, the support for inter-object relationships isn’t as robust > as in Core Data (or a typical ORM.) > Also, I think the programming model is about 1/10th the complexity of Core > Data — people find it quite easy to learn. > > (Oh, also, Couchbase Server is quite a different beast, so don’t get them > mixed up. Marketing mandated the confusingly-similar names.) > > http://www.couchbase.com/communities/couchbase-lite > https://github.com/couchbase/couchbase-lite-ios > > —Jens _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
