Comments on: Crackpot Idea for Core Data Multi-User Document

By: nerkles

nerkles — Sat, 19 Nov 2005 21:38:56 +0000

I have to admit I got the book but haven't dug into it. I've concluded, at least for now, that Cocoa + Core Data is not the right approach for the project I'm working on, although this Coordinator model might actually work if somebody had time to try it and refine it.

I've decided that TurboGears is the way to go for this project (when they release 0.9 or 1.0) because part of the spec is that it's going to have frequent changes to the GUI. That's going to get too crazy... creating and deploying a new build every few weeks. Better to centralize all that implementation on the server and have "instant" deployment to the browser.

It means a slight compromise on the speed of updates to each user's View, but AJAX will keep that problem to a minimum. I'll just have to ensure only one user at a time can edit each object. It may even end up using a similar Coordinator pattern, but with AJAX, and the web server handling that coordination.

Feel free to pursue the idea though... Drop me a line if you get anywhere with it, I'd like to know it was helpful or not.

By: fondomatic

fondomatic — Tue, 15 Nov 2005 14:49:12 +0000

Did the Advanced Mac OS X Programming book provide any insight into this issue? Just curious…

By: nerkles

nerkles — Wed, 12 Oct 2005 05:21:05 +0000

Hey Jeremy,

I've been too busy, haven't tried it yet. I'll definitely post when I do. I just got my hands on Advanced Mac OS X Programming from Big Nerd Ranch, which claims to have some secret about getting Distributed Objects to work right. So we shall see!

Please drop me a line if you make any progress before I do. [nerkles at "gmail" d0t c0m].

By: Jeremy Clark

Jeremy Clark — Sat, 08 Oct 2005 16:03:36 +0000

Hello –

Did you every have any success with using Distributed Objects to vend out an NSPersistentStoreCoordinator? I too am looking to do the same thing. I’ve exprimented, but I can’t get it to work. I’m able to get the PSC in my client app, but it seems that its coming over as a DO proxy object – I think this is causing a problem in the Core Data system somewhere, but I’m not sure.

By: Gustavo Vera

Gustavo Vera — Mon, 19 Sep 2005 18:25:17 +0000

I finish publishing some information related to coreData and a multi-user application in gustavovera.blogspot.com. Regards.

By: Gustavo Vera

Gustavo Vera — Mon, 22 Aug 2005 13:33:30 +0000

Hi! I am very interested an looking for a solution to the problem of multiple users on different computers accessing the same data using core data… I have made some tests with the SQLite storeType, specifying the mergePolicy in the managedObjectContext to NSRollbackMergePolicy and allowing to the application’s user to do a commitEditing and a save against the context every time it is necessary… With this configuration i can see that, at least on my tests, the data is not corrupted during simultaneous operations of two application instances…. but also is hard to keep synchronized the two applications… the fetch recovers the new objects, added from the other running instance, but don’t recover the changes done in one of the existing and previously added ones… The idea of a coordinator server is not bad… but a think that is going to make the things very complicated in comparison… Somebody has some kind of little example already running??? And another completely different question…. what i should do to become a member or to enter to the mailing lists published in cocoabuilder? I can’t find that info, and the “terms of use” at the bottom of each page doesn’t seem to work…

By: nerkles

nerkles — Wed, 10 Aug 2005 13:28:21 +0000

JS– Thanks for trying that out! When I have time to mess with this, I’d like to try it both ways. I think for my case the network traffic wouldn’t be so bad since there will be < 20 users.

By: JS

JS — Wed, 10 Aug 2005 10:05:00 +0000

Hi I spent a little time looking at this problem this weekend, but i couldn't get it working and obviously have alot more to learn - however;

It seems to me that the proper object to vend is the Persisent Store Coordinator. Multiple MOCs can use one PSC, but each client will need it's own MOC. Also there is probably alot of messaging that takes place between the MOC and the UI widgets because of the observing stuff that would clog up the network.

By: nerkles

nerkles — Tue, 09 Aug 2005 18:18:39 +0000

I just thought of the most obvious thing. Could it be this easy? Use Distributed Objects to "vend" the ManagedObjectContext? One instance of the app with access to the data store could vend, while the others use a vended MOC?

Well, that would sure simplify things. I won't have time to try it for a couple weeks, but if anyone knows whether this is even possible, it'd be good to know.

By: JS

JS — Sat, 06 Aug 2005 16:18:49 +0000

I have not been able to spend the time with core data that I wanted to, but I have also thought about what would be the best way to achieve a client server setup with core data. It seems to me that what would be needed is some kind of server/deamon app to be written that would use core data to create a MO context for each connection. The client app could then use Distributed Objects or some other suitable mechanism to treat that server side MO context as it’s datasource for its own local core data stack. Can you do nested MO contexts the way you could do nested EOF editing contexts? If DO worked, would the client app even need a core data stack? Might only need the proxy for the remote MOcontext.

I think that this is sorta like the arrangement used in the WO/EOF Java Client app arrangement. I think that if you looked at how that was setup you could get some ideas. Bury all actual file access in your coordinator app and have the clients connect to it, not the file.

(fancy DO example here: http://homepage.mac.com/azc/DistributedWidgets/)