On Jul 13, 2012, at 12:38 PM, Flavio Donadio <fla...@donadio.com.br> 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 (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
