How to have different NSManagedObjectContexts?

Question

I have only one database model schema in my app, so IMHO, NSManagedObjectModel and NSPersistentStoreCoordinator objects might reside in main app delegate class for accessing from other parts of the app. However, I would like to have different NSManagedObjectContexts objects for various parts of my app because I will use multithreading.

From my personal database experience, I assume NSManagedObjectContext is somehow similar to the concept of database transaction. So, it's logical to have separate context objects for various multi-threaded parts of my app in order to avoid committing unwanted changes from one app part to another. When creating new project with enabled for core data, Xcode creates three essential methods in main app delegate

- (NSManagedObjectModel *)managedObjectModel{

   // reads your database model file and defined entities from defined   DataSchema.xcdatamodeld file
} 

- (NSPersistentStoreCoordinator *)persistentStoreCoordinator{

  // uses already read database model and initializes defined sqlite database file and returns a persistent store coordinator - a pointer to the database
}

- (NSManagedObjectContext *)managedObjectContext{

   // opens a connection (and transaction) to the database.
}

So, the question would be, is it reasonable to leave persistentStoreCoordinator and managedObjectModel methods in main app delegate (and access them through the app), but to move managedObjectContext method to those classes that need private data handling?

Answer 1

You're always going to have one main managed object context that runs on the main thread.

If you're doing background processing on another thread, you can create another NSManagedObjectContext on a background thread, pointing at the same NSPersistentStoreCoordinator.

When you save/delete/update in the background context, notifications are fired that you listen to on the main thread, and merge the changes back into the main context.

Personally, I don't have any Core Data objects in the App Delegate, because I don't think they belong there. I think Apple use that in their examples for simplicity of the example. I usually have a CoreDataStack object that is passed around where I need it.

You could look at a higher level Core Data API, such as Magical Record. I've just started using this and it's pretty useful, and removes a lot of the boilerplate code you get from Core Data. It's written by Marcus Zarra and team, a guy who apparently knows a lot about Core Data.

In iOS 5, Core data was improved by allowing ManagedObjectContexts to have a parent context. So in your case, your background contexts would be children to the parent context, and apparently it's a lot easier to merge back in. I haven't tried this yet though.

Answer 2

So, it's logical to have separate context objects for various multi-threaded parts of my app in order to avoid committing unwanted changes from one app part to another.

It is possible to have multiple contexts, which is a practice used widely.

is it reasonable to leave persistentStoreCoordinator and managedObjectModel methods in main app delegate (and access them through the app), but to move managedObjectContext method to those classes that need private data handling?

• You can leave it in the app delegate, accessing it via [[UIApplication sharedApplication] delegate].
• You could create a separate singleton class containing the core data stack.
• You could just pass a pointer to the managedObjectContext between classes.
• Each viewController could create it's own context linking it to a parent context via setParentContext:.

As you can see it really depends on the complexity of your project. Generally if you have to a lot of specific retrievals and saves you might want to stick the Core Data stack in it's own class. For smaller projects why not just leave it in the app delegate and pass the context via a pointer.

Also, check out the 2011 WWDC session about Core Data. It talks about a bunch of cool new features.