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 reference the system data. When a new version of the app is installed (e.g., via iTunes):

• The new system data that comes with the update should overwrite/replace the old system data
• The user data should be modified to reference the new system data (where possible).

Question: How is this kind of migration done with Core Data? Is it feasible?

For example, let’s say my application is for managing recipes.

• Each version of the app will come with a default set of recipes.
• The user can not edit these “official” recipes.
• However, the developer may modify (or delete) any “official” recipes in future versions of the app.
• Users are allowed to add notes/comments to the “official” recipes (e.g., “bake for 45 min. instead of 30”).

When the user upgrades to a new version of the app we want to keep the user comments and try to re-associate them with matching recipes from the new, “official” set of recipes. Is this possible/feasible with Core Data? Or perhaps I should just use a plain “database” solution (e.g., SQLite and traditional create/read/update/delete operations)?

Thanks!

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.