Ah, finally I can ask the Core Data question that's been bugging me
for a long time.
I really like how easy it is to use NSPersistentDocument, and how
well-integrated it is with IB and Bindings. However, this class
assumes the standard 1-file, one NSDocument paradigm. It creates its
coordinator automatically, and is tied to a single file/URL.
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.
As an example, say I'm writing a program to keep track of Personnel.
The primary entities would be Person and Group. I'd like to store all
these entities in a single SQLite database using CoreData. However,
rather than using a single "document" with a master/detail interface,
I'd rather have one window showing a list of all Persons or Groups,
and a separate editor "document" window to edit each Person or Group.
These editor windows should behave just like normal a normal
NSPersistentDocument with regards to how it interacts with the store,
but I want all of the documents to read and write from the same
database file on disk. Changes made in one Person editor would not
affect those in any other editor until the document was saved (i.e.
the changes committed).
What's the best approach for handling a paradigm such as this?
Thanks,
- Paul M
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
