Re: Multi-User using Core Data?
Re: Multi-User using Core Data?
- Subject: Re: Multi-User using Core Data?
- From: Nicko van Someren <email@hidden>
- Date: Fri, 10 Jun 2005 09:55:43 +0100
On 9 Jun 2005, at 21:50, Jeff LaMarche wrote:
Apple obviously made a conscious decision not to support remote
databases with Core Data - they already had an architecture in
place to do it (EOF), so it clearly could have been done had they
really wanted to. I have no reason if their reason not to include
that support was technical, political, or what, but that being
said, there are a couple of options give use a single data store
for applications on separate machines.
I think that the main reason for not doing this is that CoreData is
essentially free but you have to pay for the Enterprise Objects
framework, so they felt it was necessary to "cripple" the freeware to
a specification that is useful for desktop applications but left the
corporates with deep pockets needing to buy EOF. This seems a
perfectly reasonable business decision, even if it's a little
annoying for those of us who want to run enterprise grade
applications but don't have the cash!
1) You could make the SQLite data file location a preference value,
and set it to a network drive location.
This is fine until you have two applications accessing the same data
at the same time at which point the memory cache and the file will
get woefully out of sync and "bad things" will happen.
2) You could write a small, headless server application that would
vend the data to you client applications using Distributed Objects.
This has many merits, though I've no idea how well things like KVO
work on distributed objects.
3) Create a subclass of NSPersistentStoreCoordinator that uses a
remote database. This would be no mean feat, but you would likely
make many friends by doing it =)
Actually, as I noted before (http://www.cocoabuilder.com/archive/
message/2005/5/18/136233) what you need to do is build a few new
subclasses of the NSSQLAdapter, NSSQLStatement and related classes.
It's clear from examining the guts of CoreData that it is perfectly
capable of working on other types of database back end. You would
need to arrange a suitable set of triggers and monitors on any tables
that are having their content cached but this is standard practice in
multiple-access database programming. I now more or less understand
how to build this but I don't really have the time or the database
experience to do this properly. If someone out in CocoaLand with
some DB experience and lots of free time wants to drop me a line I'd
be happy to tell them what I know.
Nicko
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden