Hello, people!
I'll bring this subject to surface again. I know it pops here and there from
time to time, but I've never seen anything conclusive, besides advice to steer
off this idea.
For a long time, I have wanted to develop a "pseudo-CRM" software for my small
business. It will be used for simple things, like managing customer and product
data, sending quotes and invoices and stuff like that. I need it to be
multiuser and I am fed up with web-based software. We use only Macs. Period.
From what I've read in this and other lists, and also lots of forums, Core Data
wasn't meant for multiuser access and I understand it. But...
I am reading Marcus Zarra's book on Core Data ("Core Data - Apple’s API for
Persisting Data on Mac OS X") and I have to say the book is excellent. And it
got me thinking about this project again.
One of the problems in using Core Data with multiple users accessing the same
persistent store is concurrency. But I've seen techniques for that, such as
using multiple MOCs. Marcus Zarra's book talks about it in chapter 9, about
multithreading. I've seen it in Apple's documentation also.
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?
What do you guys think about it? Is it a bad idea? I've studied a lot of
alternatives (BaseTen, ODBC, Web Services), but I can't wrap my head around
them...
Cheers,
Flavio
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
