Database Reference
In-Depth Information
other changes, just follow a few simple rules for Core Data to create a mapping
model. In the new model, changes must fit an obvious migration pattern, such as:
1. Deleting entities, attributes or relationships;
2. Renaming entities, attributes or relationships using the
renamingIdentifier
;
3. Adding a new, optional attribute;
4. Adding a new, required attribute with a default value;
5. Changing an optional attribute to non-optional and specifying a default value;
6. Changing a non-optional attribute to optional;
7. Changing the entity hierarchy;
8. Adding a new parent entity and moving attributes up or down the hierarchy;
9. Changing a relationship from to-one to to-many;
10. Changing a relationship from non-ordered to-many to ordered to-many (and
vice versa).
Note
: Check out Apple's documentation for more information on how Core
Data infers a lightweight migration mapping:
https://developer.apple.com/library/Mac/DOCUMENTATION/Cocoa/Conceptual
/CoreDataVersioning/Articles/vmLightweightMigration.html
As you can see from this list, Core Data can detect, and more importantly,
automatically react to, a wide variety of common changes between data models. As
a rule of thumb, all migrations, if necessary, should start as lightweight migrations
and only move to more complex mappings when the need arises.
As for the migration from UnCloudNotes to UnCloudNotes v2, the image property
has a default value of
nil
since it's an optional property. This means Core Data can
easily migrate the old data store to a new one, since this change follows item 3 in
the list of lightweight migration patterns.
Build and run, and your old notes have returned! Core Data has migrated the data
store automatically using an inferred mapping model.
The non-
nil
value for the
store:
entry in the logs is a nice confirmation that the
migration actually happened and that there's now an
NSPersistentStore
object
representing the store.
