Re: Core Data Multiuser
Re: Core Data Multiuser
- Subject: Re: Core Data Multiuser
- From: Jens Alfke <email@hidden>
- Date: Mon, 16 Jul 2012 14:39:42 -0700
On Jul 13, 2012, at 12:38 PM, Flavio Donadio <email@hidden> wrote:
> On chapter 11, the book talks about "distributed Core Data", using Distributed Objects to exchange NSManagedObjects between a client app and a server app. The latter deals with the MOC and the persistent store. Zarra warns about scalability problems, since NSManagedObjectContext is not thread-safe and, the, all clients' data would be dealt with serially... But, what if I used one MOC per client?
In my experience — and yes I have tried it — using DO between multiple computers is a nightmare. I know it sounds so simple and appealing, but that's because it tries to sweep all the hard problems of networking[1] under the rug. The problems remain, and will bite you, hard.
The inconvenient truth is that sending a message over a network is not at all the same as sending an Objective-C message between two objects, no matter what kind of clever wrapping is used to make it look like it. Network messages are orders of magnitude slower, they are unreliable for many different reasons, and they're not trustable unless you are very, very careful about authentication and sandboxing.
There are basically two realistic ways to do what you want to do:
(1) Client-server. The database lives on one server machine, as does the "business logic" (I hate that term) that manages your app. This could definitely be implemented with Core Data if you like. The client app just focuses on the UI, and there is some protocol by which it talks to the server to fetch data and to tell it to do stuff. In other words, the client app will not use Core Data.
(2) Synchronized. Every client has a copy of the database, and the app operates on the local database. But the clients have to stay in sync by sending messages to the server whenever they make changes, and receiving notifications from the server when some other client makes a change. If conflicting changes are made, there has to be a way to resolve them.
The bad news: Approach #1 is straightforward but means you have to abandon Core Data on the client, and design and implement your own network protocol, which is time-consuming. Approach #2 is lovely when it works but I assure you from experience that synchronization is very, very difficult to implement from scratch.
I hate to make this post sound like an ad, but I'm developing (for my employer, Couchbase) a framework that implements #2. It's based on CouchDB[2], a very popular nonrelational ("NoSQL") distributed database that is really, really good at synchronization. My framework, TouchDB,[3] lets Mac or iOS or Android apps store databases locally, operate on them locally, and then replicate in real time with a CouchDB server. If there are multiple clients syncing with the same server, it's exactly the solution #2 I outlined above.
Now, TouchDB isn't compatible with Core Data. But it does have a pretty solid Cocoa API that has an object-model layer a bit like a simplified Core Data. The people who've been using it like it a lot.
—Jens
[1]: http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing
[2]: http://couchdb.apache.org
[3]: http://touchdb.org
_______________________________________________
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