Can Core Data handle my “system vs. user data” migration needs?

Question

My iPhone app will have read-only \"system\" data AND read/write \"user\" data (stored either using Core Data or a custom SQLite db). The user data may ref

Answer 1

You should have two persistent stores. A read only store that is in your bundle and a read/write store that is in the documents directory.

You can add both stores to the NSPersistentStoreCoordinator and access them both from one NSManagedObjectContext.

If both stores have the same entity then you will want to call -assignObject:toPersistentStore: to tell Core Data which store to save the entity into. If each underlying model has different entities then this is not necessary.

In addition you can "link" notes to a read-only recipe by making sure each recipe has a unique identifier (that you create) and the note stores that so that you can use a fetched property to retrieve the associated recipe and associates notes.

ObjectID

First, do not use the -objectID for linking between stores. It can and does change during migration (and other times) which will make your migration MUCH uglier than it needs to be.

Migration

Migration is very straight-forward. If you need to change the read-only data model, just change it and include the new version with your application.

If you need to change the read-write model, create a new model, use automatic migration during testing and when you are ready to ship, write a NSMappingModel from the old version to the new version.

Because the two persistent stores (and their associated models) are not linked there is very little risk with migration. The one "catch" is that the template code for Core Data will not be able to automatically resolve the source model for migration. To solve this issue you need to step in a little bit and help it out:

1. Stand up your destination NSPersistentStoreCoordinator and watch for an error. If you get a migration error:
2. Find the source model(s) and create an instance of NSManagedObjectModel with all of the appropriate source models.
3. Create an instance of NSMigrationManager and give it the source and destination models
4. Call - migrateStoreFromURL: type: options: withMappingModel: toDestinationURL: destinationType: destinationOptions: error: to kick off the migration
5. Profit!

It is a bit more work to handle the migration in this way. If your two models are very separated, you could do it a little different but it will require testing (as all things do):

1. Catch the migration error
2. Stand up a new NSPersistentStoreCoordinator with just the persistent store (and model) that needs to migrate.
3. Let that one migrate.
4. Tear down that NSPersistentStoreCoordinator and attempt to stand up your main NSPersistentStoreCoordinator again.