Re: CoreData: Single coordinator, multiple contexts?

FROM : Paul Mix
DATE : Sat Apr 30 16:38:53 2005

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