Core Data Migration Across Multiple Version Upgrades

Question

I have an iPhone app that uses Core Data.

I did an update and used Lightweight Migration to go from V1 to V2 of my MOM (Managed Object Model). This worked perfectly.

What happens when I want to go to V3 (and beyond) of my MOM?

• If I decide to continue with Lightweight Migration, will it automatically deal with migrating from V1 to V3 and V2 to V3 of my MOM, or do I need to do something extra?
• If I decide to use a mapping model, what happens? How do I deal with upgrading both V1 and V2 MOM's to V3? Do I need to create a mapping model for both V1 to V3 and V2 to V3?
• This question goes further ... what happens when I have V6 MOM and still need to support the possibility of upgrading from a V1 MOM?

Another question is what is the best way to determine the version of the current MOM? Should I use isConfiguration:compatibleWithStoreMetadata:

Thanks for any assistance. I am loving Core Data. But it sometimes makes my head spin and I get confused, which is why I am seeking some sage wisdom.

Raquel

Answer 1

The initial posting was now many months ago, but I think that the best answer is found in Marcus Zarra's Core Data book (or online in the code examples). Google for "progressivelyMigrateURL" and one will find code for progressively iterating through models - which would allow one to create mappings from model n to model n+1, while not worrying about the combinatorial explosion for creating mappings between all pairings of models.

This may result in a slower migration at run time. I haven't investigated this.

Succussion

It is definitely slower at run time than being able to jump directly from v1 to v15. However performance testing will help to determine whether my progressive migration will work or if you will need to do all of the maps. – Sciomachy

The source code with the progressivelyMigrateURL method is from the Pragmatic Bookshelf book "Core Data". Link is here: pragprog.com/titles/mzcd/source_code – Sweltering

Macrus Zarra's code is great, and I highly recommend his book on Core Data. That said, I had to make the following change to it to prevent it from recursing infinitely if it discovers the .mom files in the wrong order: gist.github.com/2321704 (without this, there's a chance it will keep trying to migrate to the same version it's already on, FOREVER.) – Drug

Note that since ios 7 sqlite creates wal and shm files you will need to delete after the first migration. See this : #23461157 for more. – Kutzenco

DO lightweight migrations also require progressive migration? – Issi

Answer 2

I went with ordinary migration using createDestinationInstancesForSourceInstance.
The snippet shows how to override that method and how to get the sourceVersion of the model to migrate. The actual migration is happening in the helper class TZMigrationHelper.

- (BOOL)createDestinationInstancesForSourceInstance:(NSManagedObject *)sInstance entityMapping:(NSEntityMapping *)mapping manager:(NSMigrationManager *)manager error:(NSError **)error
{
    float sourceVersion = [[[mapping userInfo] valueForKey:@"sourceVersion"] floatValue];
    if(sourceVersion <= 0.9)
    {
        mapping = [TZMigrationHelper addAttributeMappingForDerivedRTFProperties:sInstance mapping:mapping propertyName:@"someProperty"];
        mapping = [TZMigrationHelper addAttributeMappingForDerivedRTFProperties:sInstance mapping:mapping propertyName:@"anotherProperty"];
        mapping = [TZMigrationHelper addAttributeMappingForDerivedRTFProperties:sInstance mapping:mapping propertyName:@"oneMoreProperty"];     
    }
    return [super createDestinationInstancesForSourceInstance:sInstance entityMapping:mapping manager:manager error:error];
}  

Team

From taking a closer look at the Apple CoreDataVersioning.pdf document, it states that the migration process "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." This implies that I do need to create an increasing number of mapping models for each rev of my database. So, for V3, I would need a V1 to V3 mapping model as well as a V2 to V3 mapping model. So, I am confused by your "fall through" logic and why it is needed. – Raquel

Did you try if it is enough to define multiple models to migrate over multiple versions? I think I will remove the fall-through approach above as I am also not sure if it is needed. – Team