Can’t you use NSIncrementalStore to talk with REST services as a backend for Core Data? I remember seeing some articles on this.
Yes: http://sealedabstract.com/code/nsincrementalstore-the-future-of-web-services-in-ios-mac-os-x/ http://stackoverflow.com/questions/17813652/nsincrementalstore-using-local-and-remote-data I’ve never tried it, but it seems like its been forgotten about. On Oct 16, 2013, at 4:57 PM, Jens Alfke <j...@mooseyard.com> wrote: > > 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/alex%40webis.net > > This email sent to a...@webis.net Alex Kac - President and Founder Web Information Solutions, Inc. "To educate a person in mind and not in morals is to educate a menace to society." -- Theodore Roosevelt _______________________________________________ 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
