Swift - Coredata Migration - Set New Attribute Value According to Old Attribute Value

Swift - Coredata Migration - Set new attribute value according to old attribute value

Lightweight migration can't do this. You'll have to create a mapping model and a subclass of NSEntityMigrationPolicy. It's not difficult but it's unfamiliar territory for most iOS developers. The steps run like this:

  1. Create the mapping model. In Xcode, File --> New --> Mapping Model. When you click "Next", Xcode will ask for the source (old) and destination (new) model files for this mapping.
  2. The model file will infer mappings where possible. Everything else will be blank. With your type and some other properties, it'll look something like the following. Entries like $source.timestamp mean to copy the existing value from before the migration.

Initial mapping


  1. Create a new subclass of NSEntityMigrationPolicy. Give the subclass an obvious name like ModelMigration1to2. This class will tell Core Data how to map the old boolean value to the new integer value.

  2. Add a method to the subclass to convert the value. Something like the following. The method name doesn't matter but it's good if you choose something descriptive. You need to use ObjC types here-- e.g. NSNumber instead of Int and Bool.

     @objc func typeFor(isSaved:NSNumber) -> NSNumber {
    if isSaved.boolValue {
    return NSNumber(integerLiteral: 1)
    } else {
    return NSNumber(integerLiteral: 2)
    }
    }
  3. Go back to the mapping model and tell it to use your subclass as its custom mapping policy. That's in the inspector on the right under "custom policy". Be sure to include the module name and class name.

Custom Policy


  1. Tell the mapping model to use that function you created earlier to get values for the type property from the old isSaved property. The following says to call a function on the custom policy class named typeForIsSaved: (the : is important) with one argument, and that the argument should be the isSaved value on $source (the old managed object).

Custom attribute mapping

Migration should now work. You don't have to tell Core Data to use the mapping model-- it'll figure out that migration is needed and look for a model that matches the old and new model versions.

A couple of notes:

  • If you crash with an error that's something like Couldn't create mapping policy for class named... then you forgot the module name above in step 5 (or got it wrong).
  • If you get a crash with an unrecognized selector error then the method signature in step 4 doesn't match what you entered in step 6. This can also happen if you forget to include @objc in the function declaration.

Core Data Migration custom migration

So I've found the reason for the issue after speaking to apple, its because I don't have a V1 to V2 model, just V2 to V3. Without that, all mapping models are ignored,

They've also said the mapping isn't running correctly as it crashes with "unrecognized selector sent to instance" even though ititss correct, that its a bug.

They've advised to use createDestinationInstances as a workaround so need to figure that out

Adding a new entity to coredata - can I still use lightweight migration?

Check the core data video "Mastering core data" from wwdc 2010. They talk about migration for your specific case. Long story short: yes, you can use lightweight migration. Just pass the options dictionary when initializing the NSPersistentStoreCoordinator instance:

NSDictionary *dictionary=[NSDictionary dictionaryWithObjects:@[ [NSNumber numberWithBool:YES], [NSNumber numberWithBool:YES]] forKeys:@[ NSMigratePersistentStoresAutomaticallyOption, NSInferMappingModelAutomaticallyOption]];


Related Topics



Leave a reply



Submit