FROM : mmalcolm crawford
DATE : Sat Apr 30 01:47:09 2005
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.
> 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?
>
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...
NSManagedObjectContext *moc = [[NSManagedObjectContext alloc]
init];
[moc setPersistentStoreCoordinator:[[NSApp delegate] coordinator];
mmalc
AppDelegate ivar:
NSPersistentStoreCoordinator *coordinator;
- (NSPersistentStoreCoordinator *) persistentStoreCoordinator {
if (coordinator != nil) {
return coordinator;
}
NSError *error;
NSURL *url;
NSString *path = @"** path to your shared store **";
// check path exists -- perhaps create it if it doesn't, else
report an error
url = [NSURL fileURLWithPath: path];
coordinator = [[NSPersistentStoreCoordinator alloc]
initWithManagedObjectModel: [self managedObjectModel]];
if (![coordinator addPersistentStoreWithType:MY_STORE_TYPE
configuration:nil
URL:url
options:nil
error:&error])
{
[[NSApplication sharedApplication] presentError:error];
}
return coordinator;
}
DATE : Sat Apr 30 01:47:09 2005
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.
> 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?
>
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...
NSManagedObjectContext *moc = [[NSManagedObjectContext alloc]
init];
[moc setPersistentStoreCoordinator:[[NSApp delegate] coordinator];
mmalc
AppDelegate ivar:
NSPersistentStoreCoordinator *coordinator;
- (NSPersistentStoreCoordinator *) persistentStoreCoordinator {
if (coordinator != nil) {
return coordinator;
}
NSError *error;
NSURL *url;
NSString *path = @"** path to your shared store **";
// check path exists -- perhaps create it if it doesn't, else
report an error
url = [NSURL fileURLWithPath: path];
coordinator = [[NSPersistentStoreCoordinator alloc]
initWithManagedObjectModel: [self managedObjectModel]];
if (![coordinator addPersistentStoreWithType:MY_STORE_TYPE
configuration:nil
URL:url
options:nil
error:&error])
{
[[NSApplication sharedApplication] presentError:error];
}
return coordinator;
}
| Related mails | Author | Date |
|---|---|---|
| James Clause | Apr 29, 16:49 | |
| John Brownlow | Apr 29, 17:36 | |
| Scott Stevenson | Apr 29, 19:07 | |
| John Timmer | Apr 29, 22:34 | |
| John Timmer | Apr 29, 23:28 | |
| Bill Bumgarner | Apr 30, 00:00 | |
| John Timmer | Apr 30, 00:29 | |
| Scott Ellsworth | Apr 30, 00:43 | |
| Chris Hanson | Apr 30, 00:56 | |
| Paul Mix | Apr 30, 01:03 | |
| John Timmer | Apr 30, 01:13 | |
| Scott Stevenson | Apr 30, 01:15 | |
| Scott Stevenson | Apr 30, 01:18 | |
| mmalcolm crawford | Apr 30, 01:47 | |
| Bill Bumgarner | Apr 30, 09:49 | |
| Paul Mix | Apr 30, 16:38 | |
| mmalcolm crawford | May 1, 00:09 |






Cocoa mail archive

