Do multiple versions of xcdatamodel mean that we need multiple xcmappingmodel files?

Question

I have multiple versions of xcdatamodel files:

app1.0.xcdatamodel
app1.1.xcdatamodel
app1.2.xcdatamodel (current)

Does this mean I need multiple combinations of xcmappingmodel files to cover all upgrade scenarios?

app1.0_to_app1.1.xcmappingmodel (had this already)
app1.1_to_app1.2.xcmappingmodel (is it iterative?)
app1.0_to_app1.2.xcmappingmodel (too much?)

Thanks!

Answer 1

Core Data requires that you create a mapping model to go from the current version of the data store to the latest version of the data store. This means that you will need to make one that goes from v1 -> v2 and v2 -> v3 and v1 -> v3.

From Core Data Versioning and Migration Guide

Tries to find a mapping model that maps from the managed object model for the existing store to that in use by the persistent store coordinator. Core Data searches through your application’s resources for available mapping models and tests each in turn. If it cannot find a suitable mapping, Core Data returns NO and a suitable error.

Note that you must have created a suitable mapping model in order for this phase to succeed.

As discussed in this Apple Document Core Data Mapping

Answer 2

You could implement progressive data migration. Look for progressivelyMigrateURL in here http://media.pragprog.com/titles/mzcd/code/ProgressiveMigration/AppDelegate.m

Answer 3

The progressivelyMigrateURL is a great sample, but I don't think you actually need it as versions of your document appear as long as you develop the application so every time you need as many mapping models as the count of supported versions of the data model minus one and not more (for example you don't need the app1.0_to_app1.1.xcmappingmodel as 1.1 version is not the latest version any more). Every time when you create a new version you need just to correct a target model in every mapping model you have and add one more if needed, maybe you will need to generate new ones and remove old ones though. The fact is that migration in one stage (which doesn't force you to create more mapping models compared to the progressive one) is much much faster in runtime as you may notice. You also don't need to create mapping models for trivial cases and either use a Lightweight Migration (use The Default Migration Process instead if concrete situation needs a mapping model which cannot be generated in runtime (of course you need to have it in your app bundle)) or migrate with a help of the mapping model created in runtime with the help of the inferredMappingModelForSourceModel:destinationModel:error: method of the NSMappingModel class and then customized in code if needed (you will need to trigger migration manually in this case by calling the migrateStoreFromURL:type:options:withMappingModel:toDestinationURL:destinationType:destinationOptions:error: method of NSMigrationManager instance as far as I understand). Good luck!