2

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!

clint
  • 14,402
  • 12
  • 70
  • 79
  • Note: I have a high-level understanding of how you can migrate an existing Core Data object graph to a new one data model using the tools that come with Core Data. In this case, I'm more concerned with replacing or modifying the data itself as part of that migration. I have a good idea of how to implement a non-CoreData solution using two separate SQLite databases. But considering some of the nice features it provides, I'd really like to use Core Data! – clint Jul 15 '10 at 17:08
  • Here's a related and possibly helpful forum discussion in which someone suggests using two separate Core Data "managed object contexts" (one system, one user). Unfortunately, it appears that "cross-store relationships" are a no-no. http://www.cocoabuilder.com/archive/cocoa/290438-core-data-multiple-stores-saving-problems.html – clint Jul 15 '10 at 17:19

1 Answers1

11

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.
Marcus S. Zarra
  • 46,571
  • 9
  • 101
  • 182
  • 1
    Thanks for the advice Marcus (and for the wealth of knowledge you've shared online, in general)! Do you have any thoughts on how one might handle data migration in this scenario? – clint Jul 15 '10 at 18:29
  • You can also use the URL of a recipe's `objectID` as its unique ID; I don't think there's any need to create a separate unique ID for each entity that you with to link across stores. – Barry Wark Jul 15 '10 at 18:51
  • 3
    Awesome, thanks for adding such detailed info on migration to your answer. Considering the number of articles/videos/etc I've seen from you related to Core Data, I kinda feel as if I just asked a physics question and Stephen Hawking answered it. Cheers. – clint Jul 15 '10 at 19:24
  • Using this approach is it then possible to build a predicate to fetch all recipes that (for example) have user comments set? Or do I have to manually do this by building a list of id's and using an IN predicate? – Alex Deem May 03 '11 at 02:10
  • It is a little complicated in that you may need to do a subquery to get exactly what you are looking for. – Marcus S. Zarra May 05 '11 at 03:59