On Oct 16, 2013, at 8:24 AM, Flavio Donadio <fla...@donadio.com.br> wrote:
> So, that's why we need another tier: an application server between the client > and database server, to manage locking and concurrency (among other things). > This is really annoying, as we have to deal with things like web services > (or, even worse, custom protocols), data encoding into structures meant only > for client/server communication (stuff like XML, JSON or whatever). It’s inevitable. You can’t safely make a client-server connection over the Internet look like a traditional database connection. They have very different characteristics: reliability, latency, throughput, security. I’m offline right now, but look up “distributed computing fallacies” for a great description of all the ways network requests can get into trouble. So using Core Data to hide the fact that you’re talking to an Internet service would be a bad idea. This is why REST APIs (for example) don’t use transactions, send more data at once, have flexible schemas, etc. > In cases where a partially connected application is desired, even if you want > to use CoreData in the client, it's still very hard to do. You have to have > two identical models (one for the server, one for the client -- often in > different formats) and keep them in sync as you add/change features to/in the > app. You also have to generate NSManagedObjects from the data you receive > from the app server and save them back when the objects modified. > AFIncrementalStore helps, but it could be even easier. Yeah, I don’t think CoreData is the right tool for that kind of job. In my day job I work on a data sync engine (Couchbase Lite) that uses a REST-based transport protocol, and the app API it provides is lower-level than Core Data; but on the other hand it’s a lot simpler. The world the developer sees is one with a local database, one that may change asynchronously as the background replication task pulls in new revisions from the server. This can result in conflicts (just like a “git pull”, say) that need to be resolved. It’s a pretty nice way to work, since it lets you ignore the network and think in terms of JSON objects and revisions instead. —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
