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
