Re: Core Data with ODBC databases?
Re: Core Data with ODBC databases?
- Subject: Re: Core Data with ODBC databases?
- From: Jens Alfke <email@hidden>
- Date: Wed, 16 Oct 2013 15:57:38 -0700
On Oct 16, 2013, at 8:24 AM, Flavio Donadio <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden