Can I use "Automatic Lightweight Migration" if my already release v1 didn't have a versioned Core Data model?

Question

Can I use "Automatic Lightweight Migration" if my already release v1 didn't have a versioned Core Data model?

If yes, are there any key changed to the documented steps I need to apply?

Answer 1

Not only can you do this, in one sense it is the only way you can do this. From the Apple Documentation, "To create a versioned model, you start with a normal model..."

Your v1 had a normal model. As long as you have that model, and you follow the steps linked in that tutorial to create a versioned model, lightweight migration will work—if your migration meets the usual lightweight migration requirements. The lightweight migration happens in your v2 app (or in v1.1 or whatever). The data model that was in your v1 app essentially has no relevance. What Core Data needs is to find that the new v2 app has a copy of the data model that matches what is found in the Core Data store on the local device, and has a new data model that describes how you want the data to be stored from this point forward. If the changes required meet the requirements for lightweight migration, it then does it.

What are those requirements? From the Apple documentation on Lightweight Migration:

To perform a lightweight migration, Core Data needs to be able to find the source and destination managed object models itself at runtime. (Core Data searches the bundles returned by NSBundle’s allBundles and allFrameworks methods.) It must then analyze the schema changes to persistent entities and properties and generate an inferred mapping model. For Core Data to be able to do this, the changes must fit an obvious migration pattern, for example:

• Simple addition of a new attribute
• A non-optional attribute becoming optional
• An optional attribute becoming non-optional, and defining a default value.

If you rename an entity or property, you can set the renaming identifier in the destination model to the name of the corresponding property or entity in the source model. You typically set the renaming identifier using the Xcode Data Modeling tool, (for either an NSEntityDescription or an NSPropertyDescription object). In Xcode, the renaming identifier is in the User Info pane of the Detail Pane, below the version hash modifier (see The Browser View in Xcode Tools for Core Data). You can also set the identifier at runtime using setRenamingIdentifier:. For example, to handle

• Renaming of an entity Car to Automobile,
• and Renaming the Car’s color attribute to paintColor

you would include the following code after loading the destination data model, and before attempting to open a store file:

NSEntityDescription *automobile = [[destinationModel entitiesByName] objectForKey:@"Automobile"];
[automobile setRenamingIdentifier:@"Car"];
NSPropertyDescription *paintColor = [[automobile attributesByName] objectForKey:@"paintColor"];
[paintColor setRenamingIdentifier:@"color"];

In summary, you didn't miss the boat, and it's not too late to make use of these features of Core Data. :) And to answer your specific question, there is nothing you need to change from the standard steps outlined in the documentation.

Later update Further thoughts based on your comment to another answer, where you said:

so just to confirm, I don't have to in XCode back track my core data model to what it looked like a v1 and then version it then? So I can just create the first core data model version at the point where my application is at v2?

From what you are saying here, the issue would appear to be different to the initial question. Your initial question says that you have already released v1 of your app, without explicitly adding a versioned model. However, this statement implies that you have made changes to your core data model for v2 of your app, without first creating a versioned data model. This is quite a different thing.

If this is the case, then your job is more difficult. However, you can retrieve what you need presuming you keep backups of your source code or manage your code in a repository like git (and I would recommend all developers do both). If you've already changed your core data model for v2, what you need to do is turn the current data model into a versioned model, then restore/checkout a copy of v1 of your app, copy the core data model (the *.xcdatamodel file) from there into your current project, so that you then have both the v1 data model and your newer one. Then you will potentially be able to use lightweight migration, as discussed above.

Note that the key issue here is when you changed your data model. Whether your app is called v1 or v2 is essentially irrelevant to the question, other than obviously that it may be that you introduced changes to the data model at the same time you changed the version number to v2 of the app.

Answer 2

Save off your current non-versioned model file (the .xcdatamodel package).

Now, create a new model version. You will have instead of a single .xcdatamodel package, a .xcdatamodeld file. Right click on it in Finder, select "show package contents". That opens it as a directory - drag your old .xcdatamodel file into that directory alongside the new versioned .xcdatamodel package.

Now an automatic migration should work if it's possible, you may not need a mapping model. Test to be sure though!!!

I have used this approach in a production application and it did work. As long as CoreData can find both the current model the app is using, and the model the new version of the model the application relies on it can attempt the automatic migration.

Answer 3

yes it is possible because by creating the new version you can also create a version mapping file. This file tells the application which keys will be changed to which keys in the new version (and of course which one are deleted and created)

the apple documentation: http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/vmMappingOverview.html