25

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.

westsider
  • 4,929
  • 5
  • 33
  • 51
thevoid
  • 659
  • 7
  • 12

2 Answers2

7

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.

westsider
  • 4,929
  • 5
  • 33
  • 51
  • 1
    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. – Marcus S. Zarra May 18 '10 at 15:48
  • The source code with the progressivelyMigrateURL method is from the Pragmatic Bookshelf book "Core Data". Link is here: http://pragprog.com/titles/mzcd/source_code – bentford May 15 '12 at 20:01
  • 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](http://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.) – Phil Calvin May 19 '12 at 15:10
  • 2
    Note that since ios 7 sqlite creates wal and shm files you will need to delete after the first migration. See this : http://stackoverflow.com/questions/23460657/coredata-migration-in-ios-7 for more. – Ben G Jun 06 '14 at 09:35
  • 2
    DO lightweight migrations also require progressive migration? – SandeepAggarwal Oct 14 '15 at 05:04
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];
}
Thomas Zoechling
  • 33,182
  • 3
  • 76
  • 109
  • 1
    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. – thevoid Oct 13 '09 at 21:21
  • 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. – Thomas Zoechling Oct 14 '09 at 07:13