Re: CoreData: Single coordinator, multiple contexts?
Re: CoreData: Single coordinator, multiple contexts?
- Subject: Re: CoreData: Single coordinator, multiple contexts?
- From: Paul Mix <email@hidden>
- Date: Sat, 30 Apr 2005 09:38:53 -0500
At 4:47 PM -0700 4/29/05, mmalcolm crawford wrote:
On Apr 29, 2005, at 4:03 PM, Paul Mix wrote:
What I'm curious about is how best to use the new
CoreData/persistence classes to emulate the typical database-driven
approach, where you have a single database file, but with with
multiple documents providing interfaces to it.
*If I understand correctly what you're after*, in general, although
Core Data does handle multiple concurrent access (to address one of
the worries from a week or two ago, it does use optimistic
locking...) this is not what Core Data is intended for. If you want
a database application, use a database.
Well, I was looking into developing a custom OR-bridge for sqlite
when I first heard about CoreData, and it simply seemed to be a waste
of effort to re-invent the wheel (though I understand that CoreData
isn't really an ORB as much as a generalized modeling & persistence
tool).
Xcode already provides a template -- "Core Data Application"-- to
start down this path. It provides a single-window application where
the persistent store coordinator is set up and managed by an
application delegate. You could extract the part of the
-managedObjectContext method that creates the coordinator and use it
to implement a -coordinator method (as illustrated below). You are
free then to add as many managed object contexts as you wish...
Thanks for the feedback. Allow me to revise my idiom a bit further. A
better analogy for the app I was planning would possibly be a
"Library" type of app, with two types of stores: a single,
centralized "Library" of media (books, cd's, etc.) (stored within the
app bundle or an Application Support directory), and multiple
"Personnel" document files (one for each person, that could be saved
and moved anywhere by the end-user). All details specific to each
Person would be stored in the "Person" document file, but would have
references to entities defined in the centralized "Library" database.
Your example above is pretty much what I'd planned on doing for the
Library file. Each media item in the Library would have its own
document/editor (with different editors for different media types),
each with its own context into the same coordinator. These "item"
editors would only be accessible by an "admin" (say, the librarian).
The "Person" documents would be editable by users. They would be able
to edit their personal details (name, address, etc.). They could
browse or check out items (i.e. making references to the entities in
the "Library"), but not directly edit their characteristics.
This splitting of Library and Person docs into separate files would
allow me to use file permissions to control access (since neither
CoreData nor sqlite support privileges that I'm aware of outside
actual file permissions).
My plan was to use an NSPersistentDocument for the "Person" documents
(one person, one file/store, one "document" types), but was unsure
how to handle the editors for the "Library" items (many items, one
file/store, multiple "document" types).
Am I totally barking up the wrong tree here?
Thanks,
- Paul
_______________________________________________
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