From the Rough Cut
From the Rough Cut
From the Rough Cut
Default Migration
Sometimes, you need more control than what lightweight migration offers. Let’s say, for instance, you want to replace the Measurement entity with another entity called Amount. In addition, you want the abc attribute from the Measurement entity to end up as an xyz attribute in the Amount entity. Any existing abc data should also be migrated to the xyz attribute. To achieve these requirements, you’ll need to create a model mapping to manually specify what maps to where. When the persistent store option NSInferMappingModelAutomaticallyOption is set to YES, Core Data still checks to see if there are any model-mapping files it should use before trying to infer automatically. It is recommended that you disable this setting while you’re testing a mapping model. This way, you can be certain that the mapping model is being used and is functioning correctly.
Update Grocery Dude as follows to disable automatic model mapping:
- Set the NSInferMappingModelAutomaticallyOption option in the loadStore method of CoreDataHelper.m to @NO.
Update Grocery Dude as follows to add a new model in preparation for the migration from the Measurement entity to the Amount entity:
- Optionally take a snapshot or back up the project.
- Add a new model version called Model 3 based on Model 2.
- Select Model 3.xcdatamodel.
- Delete the Measurement entity.
- Add a new entity called Amount with a String attribute called xyz.
- Create an NSManagedObject subclass of the Amount entity. When it comes time to save the class file, don’t forget to tick the Grocery Dude target.
- Set Model 3 as the current model version.
- Run the application, which should crash with the error shown in Figure 3.5.
)
Figure 3.5 A mapping model is required when mapping is not inferred.
To resolve the error shown in Figure 3.5, you need to create a mapping model that shows what fields map where. Specifically, the requirement is to map the old Measurement abc attribute to the new Amount xyz attribute.
Update Grocery Dude as follows to add a new mapping model:
- Ensure the Data Model group is selected.
- Click File > New > File....
- Select iOS > Core Data > Mapping Model and then click Next.
- Select Model 2.xcdatamodel as the Source Data Model and then click Next.
- Select Model 3.xcdatamodel as the Target Data Model and then click Next.
- Set the mapping model name to save as Model2toModel3.
- Ensure the Grocery Dude target is ticked and then click Create.
- Select Model2toModel3.xcmappingmodel.
You should now be presented with the model-mapping editor, as shown in Figure 3.6.
)
Figure 3.6 The model-mapping editor
The mappings you’re presented with will be a best guess based on what Core Data can infer on its own. On the left you should see Entity Mappings, showing what source entities map to what destination entities. You should also see as in Figure 3.6 how the source Item entity has already inferred that it should map to the destination Item entity, which is a fair assumption. The naming standard of an entity mapping is SourceToDestination. With this in mind, notice the Amount entity doesn’t seem to have a source entity because it never existed in the source model.
Update Grocery Dude as follows to map the old Measurement entity to the new Amount entity:
- Ensure Model2toModel3.xcmappingmodel is selected.
- Select the Amount entity mapping.
- Click View > Utilities > Show Mapping Model Inspector (if that’s not visible in the menu system, press Option+⌘+3). You need to be able to see the pane shown in Figure 3.7.
- Set the Source of Amount entity mapping to Measurement. The expected result is shown in Figure 3.7.
)
Figure 3.7 Custom entity mapping of measurement to amount
Because Measurement was selected as the source entity for the Amount destination entity, the Entity Mapping Name was automatically renamed to MeasurementToAmount. In addition, the mapping type changed from Add to Transform. For more complex implementations, you can specify a custom policy in the form of an NSEntityMigrationPolicy subclass. By overriding createDestinationInstancesForSourceInstance in the subclass, you can manipulate the data that’s migrated. For example, you could intercept the values of the abc attribute, set them all to title case, and then migrate them to the xyz attribute.
The Source Fetch option shown at the bottom of Figure 3.7 allows you to limit the migrated data to the results of a predicated (filtered) fetch. This is useful if you only want a subset of the existing data to be migrated. The predicate format you use here is the same as the format you would use when normally configuring a predicate, except you use $source variables. An example of a predicate that would filter out nil source data from the abc attribute is $source.abc != nil.
Select the ItemToItem entity mapping shown previously in Figure 3.6 and examine its attribute mappings. Notice how each destination attribute has a Value Expression set. Now examine the MeasurementToAmount entity mapping. Notice there’s no value expression for the xyz destination attribute. This means that the xyz attribute has no source attribute, and you’ll need to set one using the same format used in the ItemToItem entity mapping. The original requirement was to map the abc attribute to the xyz attribute, so that’s what needs configuring here.
Update Grocery Dude as follows to set an appropriate value expression for the xyz destination attribute:
- Set the Value Expression for the xyz destination attribute of the MeasurementToAmount entity mapping to $source.abc.
The mapping model is now ready to go; however, the demo method still fetches from the Measurement entity, which doesn’t exist under the new model.
Update Grocery Dude as follows to refer to the Amount entity instead of the Measurement entity:
- Replace #import "Measurement.h" with #import "Amount.h" at the top of AppDelegate.m.
- Replace the code in the demo method of AppDelegate.m with the code from Listing 3.4. Similar to the code being replaced, this code simply fetches a small sample of Amount data instead of Measurement data.
- Run the application. The loading screen might display longer than usual due to the migration, depending on the speed of your machine.
Listing 3.4 AppDelegate.m: demo (Fetching Test Amount Data)
NSFetchRequest *request =
[NSFetchRequest fetchRequestWithEntityName:@"Amount"];
[request setFetchLimit:50];
NSError *error = nil;
NSArray *fetchedObjects =
[_coreDataHelper.context executeFetchRequest:request error:&error];
if (error) {NSLog(@"%@", error);}
else {
for (Amount *amount in fetchedObjects) {
NSLog(@"Fetched Object = %@", amount.xyz);
}
}
So long as the migration has been successful, the application won’t crash and you should see the expected result in the console log, as shown in Figure 3.8.
)
Figure 3.8 Results of a successfully mapped model
To verify the migration has persisted to the store, examine the contents of the Grocery-Dude.sqlite file using the techniques discussed in Chapter 2. The expected result is shown in Figure 3.9, which illustrates the new ZAMOUNT table (that is, Amount entity) with the data from the old Measurement entity.
)
Figure 3.9 A successfully mapped model
Make sure you close the SQLite Database Browser before continuing.