Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Core Data Migration Across Multiple Version Upgrades

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.

like image 933
thevoid Avatar asked Oct 12 '09 22:10

thevoid


People also ask

What is the difference between data migration and data replication?

When you migrate data, you do it once and after the data is moved to a new location, the old system or database is abandoned. Data replication refers to the periodic copying of data from a data source on one platform to a destination on another one, and you don't delete or discard the data source.

What is migration in CoreData?

Core Data can typically perform an automatic data migration, referred to as lightweight migration. Lightweight migration infers the migration from the differences between the source and the destination managed object models.

Is version upgrade a type of data migration?

It is usually conducted when introducing new systems and processes in an organization. The following are some common scenarios that require data migration: Replacement, upgrade, and expansion of storage systems and equipment. Legacy software upgrade and replacement.


2 Answers

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.

like image 107
westsider Avatar answered Sep 20 '22 14:09

westsider


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]; }   
like image 35
Thomas Zoechling Avatar answered Sep 18 '22 14:09

Thomas Zoechling