Database Reference
In-Depth Information
Figure 11—Completed mapping model
Xcode has already prepopulated the attributes and taken a guess at where
the attributes come from. Reviewing what has already been populated by
Xcode, we can see how the attribute mappings work. Several variables are
available for these mappings:
•
$manager
, which references the
NSMigrationManagerKey
•
$source
, which references the
NSMigrationSourceObjectKey
•
$destination
, which references the
NSMigrationDestinationObjectKey
•
$entityMapping
, which references the
NSMigrationEntityMappingKey
•
$propertyMapping
, which references the
NSMigrationPropertyMappingKey
•
$entityPolicy
, which references the
NSMigrationEntityPolicyKey
The relationship mappings are below the entity mappings. Like the attribute
mappings, these resolve the relationships for the destination entity. Normally,
these mappings resolve to an instance of an entity in the destination store
that existed in the source store. To accomplish this, the mapping for the object
at the other end of the relationship must be higher in the list (the list is
migrated in order, top to bottom). Then it is a matter of configuring the map-
ping properly, as shown in
Figure 12,
Relationship mapping
, on page 47
.
Customizing the Heavy/Manual Migration
So far, the migration we built doesn't do very much: it migrates the entities
from the old store to the new store. We need to adjust the migration to make
it perform the more complicated aspects of the migration, the ones that are
beyond the abilities of the light migration.
