core data Migration - Can we have mutiple .xcmappingmodel files in xcode?

Question

I've been using Core Data for my app and upgraded many times around (10-11 times) but users now complaining about the data lost stored in the core data database after app up gradation.

Previously, after releasing new build I am creating new model version from the old one and working on the same model and change it if required. Before releasing I am updating my .xcmappingmodel model.

Now I am ready for the next release and I have few questions in my mind:-

1) Can we have multiple .xcmappingmodel files in xcode?
2) Do we need to perform manually for the data transferring from model to model. Example :- model version 1.0 to 1.1 , 1.1 to 1.2 , 1.2 to 1.3 and soon.

Suppose any app user didn't take upgrade and working on the older version of the app (lets say 1.0) and now I am ready for 3.0 release. Do we need to provide functionality for the step by step migration ?

example:- 1.0 to 1.1 , 1.1 to 1.2 and soon till 3.0 OR his database will be automatically upgrade to the newer version with retaining of previously stored data.

Any advice on how to approach this scenario would be very much appreciated.

Thanks in advance.

Answer 1

Yes, you not only can but need multiple mapping models, for each step in data model versions. So one for 1.0 to 1.1. and one for 1.1 to 1.2

That way the store coordinator can upgrade an old model 1.0 to for example an new model 3.0. You need to tell the store coordinator to update. It is called migration.

see for example: https://developer.apple.com/library/ios/documentation/cocoa/reference/CoreDataFramework/Classes/NSPersistentStoreCoordinator_Class/NSPersistentStoreCoordinator.html#//apple_ref/occ/instm/NSPersistentStoreCoordinator/addPersistentStoreWithType:configuration:URL:options:error:

More information on CoreData migration https://developer.apple.com/library/ios/documentation/cocoa/Conceptual/CoreDataVersioning/Articles/Introduction.html

Answer 2

Core Data doesn’t automatically support progressive migration when you have several models. For example, you have model versions 1, 2, and 3. The app created a persistent store using version 1. The newer version of the app was installed with the version 3 of the model. Core Data will not automatically sequentially update the store from version 1, to version 2, to version 3. Neither if you’re using the lightweight migration, nor if you’re using the normal, heavy migration.

The lightest type of migration is, of course, a lightweight migration. You should try to use it until you can’t for some reason. It is much faster and significantly easier on the memory.

When doing the lightweight migration, Core Data has to infer the mapping model from the model that was used to create the store that is being opened to the model that is currently used in the app. In our example this means that it must be possible to infer a mapping model from version 1 to version 2, from 1 to 3, and from 2 to 3.

If for some reason lightweight migration can’t be used, and you’re creating mapping models and using migration manager, it still won’t do the progressive migration automatically for you. So you have mapping models from 1 to 2 and from 2 to 3. The app is launched, the store was previously created using version 1, and the current version is version 3. You’ll need to specify to the migration manager model 1, model 3, and the mapping model from 1 to 3.

Of course, this is totally insane. One cannot afford having mapping models between all combinations of source and destination models. The solution to this is to write your own code that would control the progressive migration process. The code would basically open the existing store, find the mapping model for it, migrate the store to the next version, and repeat.

You can find a good example on how to do this in Marcus Zarra’s Core Data book.