On Oct 17, 2013, at 8:19 AM, Brad Gibbs <bradgi...@mac.com> wrote: > Core Data is still a local cache being used by a single user, but instead of > persisting to the local disk, it’s persisting to the Postgres server.
But not directly, right? You said there was a Rails app in the middle serving up a REST API. > As for two people making changes to a record simultaneously, it would be > handled in the same way a Rails web app would handle it. Rails and Postgres > have been designed for this use case. It’s been a while since I used Rails, but the typical way that a database-driven app manages this is using transactions. Begin transaction, update rows, end transaction. That makes all the updates atomic. But NSIncrementalStore doesn’t have a notion of a transaction, because CoreData doesn’t care about concurrency, because it’s not multi-user. So if your Core Data app makes a bunch of changes, they’re going to be sent to the store, which is going to send them off as individual PUT/POST/DELETE requests. These can’t be handled atomically by the server; they’re independent requests. So they can be interleaved with other updates being made by other clients, causing trouble. Or one of them might fail for some reason, but then there’s no way to back out to a consistent state; more trouble. > As for large data sets, that’s part of the beauty of the NSIncrementalStore > approach. In its purest form, the full data set wouldn’t exist on any one > user’s device. Instead, NSIncrementalStore would fetch the data requested by > the user from the server, as needed, by firing faults. If NSIncrementalStore > worked as advertised, there would be no need to persist the entire data set > to a user’s device. I haven’t dug all the way into NSIncrementalStore yet. But the assumption you’re making is that you can take an architecture that works for a local single-user database, and transparently make it work over a worldwide network with lots of users just by [colorful metaphor ahead, not meant to be insulting!] snipping the wire labeled “SQLite” and soldering it to a wire labeled “Internet”. This is _exactly_ the kind of thing the “Fallacies Of Distributed Computing” article warns against … because those fallacies don’t apply to tightly-bound systems like CoreData+SQLite, and are often ignorable in LAN-based systems like the typical app-server+db-server setup in a data center. But on the Internet they will bite you. —Jens
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
