Database Reference
In-Depth Information
created with that model for later comparison. When a persistent store is
loaded, the first thing Core Data does is retrieve the metadata from that store.
Inside the metadata is a list of every entity type in the store, along with the
hash for that entity. Core Data then compares that list of hashes against the
hashes of the “current” MOM. If they match, everything is fine, and the store
is loaded. If they do not match, Core Data checks the options on the load
persistent store call to see whether automatic data migration is requested. If
it is not, an error message (shown in
Section 3.1,
Some Maintenance Before
We Migrate
, on page 38
) is presented to the user.
Changing the Hash Values
Surprisingly, not everything that changes inside a MOM causes the hash of
the entities inside to change. There are actually quite a few things that we
can do to a model that do not trigger data migration at all.
Changes That Alter the Entity Hash
If any of the following are changed on an entity, the entity will report a different
hash.
• Name: Changing the name of the entity
• Inheritance: Changing the parent entity
• Persistent properties: Adding or removing a property
In addition, changing the following four properties will also trigger a change
to the entity hash.
• Name: The name of the property
• Optionality/read-only: Whether the property is optional or read-only
• Attribute type: The type of value stored
• Relationship: The destination, the minimum/maximum count, the delete
rule, or the inverse
Changes That
Do Not
Alter the Entity Hash
The following changes to an entity will
not
trigger a change to the entity hash:
• Class name: Changing the
NSManagedObject
subclass
• Transient properties: Changing properties that are not saved in the per-
sistent store
• User info: Adding, removing, or changing the user info keys/values
• Validation predicates: Adding, removing, or changing the validation rules
