- Changing a Managed Object Model
- Adding a Model Version
- Lightweight Migration
- Default Migration
- Migration Manager
- Summary
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
Lightweight Migration
Whenever a new model is set as the current version, existing persistent stores must be migrated to use them. This is because the persistent store coordinator tries to use the current model to open the existing store, which fails if the store was created using a previous version of the model. The process of store migration can be handled automatically by passing an options dictionary to a persistent store coordinator when a store is added:
- When the NSMigratePersistentStoresAutomaticallyOption is true (1) and passed to a persistent store coordinator, Core Data automatically attempts to migrate incompatible persistent stores to the current model.
- When the NSInferMappingModelAutomaticallyOption is true (1) and passed to a persistent store coordinator, Core Data automatically attempts to infer a best guess at what attributes from the source model entities should end up as attributes in the destination model entities.
Using those persistent store coordinator options together is called lightweight migration and is demonstrated in bold in Listing 3.1. These options are set in an updated localStore variable of CDHelper.swift. Note that if you’re using iCloud, this is your only choice for migration.
Listing 3.1 The Local Store (CDHelper.swift localStore)
// MARK: - STORE
lazy var localStore: NSPersistentStore? = {
let options:[NSObject:AnyObject] = [NSSQLitePragmasOption:["journal_mode":"DELETE"],
NSMigratePersistentStoresAutomaticallyOption:1,
NSInferMappingModelAutomaticallyOption:1]
var _localStore:NSPersistentStore?
do {
_localStore = try self.coordinator.addPersistentStoreWithType(NSSQLiteStoreType, configuration: nil, URL: self.localStoreURL, options: options)
return _localStore
} catch {
return nil
}
}()
Update Groceries as follows to enable lightweight migration:
- Replace the existing localStore variable code in CDHelper.swift with the code from Listing 3.1. The key change to be aware of is the introduction of the bold code.
- Rerun the application, which should not throw an error.
From now on, any time you set a new model as the current version and lightweight migration is enabled, the migration should occur transparently.
Before other migration types can be demonstrated, some test data needs to be generated. Listing 3.2 contains code that generates managed objects based on the Measurement entity. You may notice that this code blocks the user interface until it finishes because the context runs on the main thread. More appropriate ways to insert test data in the background are demonstrated later in the book.
Listing 3.2 Inserting Test Measurement Data (AppDelegate.swift demo)
func demo () {
let context = CDHelper.shared.context
for i in 0...50000 {
if let newMeasurement = NSEntityDescription.insertNewObjectForEntityForName("Measurement", inManagedObjectContext: context) as? Measurement {
newMeasurement.abc = "-->> LOTS OF TEST DATA x\(i)"
print("Inserted \(newMeasurement.abc!)")
}
}
CDHelper.saveSharedContext()
}
Update Groceries as follows to generate test data:
- Create an NSManagedObject subclass of the Measurement entity. As discussed in Chapter 2, this is achieved by first selecting the entity and then clicking Editor > Create NSManagedObject Subclass... and following the prompts. When it comes time to save the class file, don’t forget to save the file in the Data Model group and check the Groceries target.
- Replace the demo function in AppDelegate.swift with the code from Listing 3.2.
- Run the application once. This inserts a lot of test data into the persistent store, which you can monitor by examining the console log. This may take a little while, depending on the speed of your machine. It’s important to have a fair amount of data in the persistent store to demonstrate the speed of migrations later. Note that the table view still remains blank because it has not yet been configured to display anything.
The next step is to reconfigure the demo function to show some of what’s in the persistent store. The code shown in Listing 3.3 fetches a small sample of Measurement data. Notice that a new option is included that limits fetched results to 50. This is great for limiting how many results are fetched from large data sets, and it is even more powerful when mixed with sorting to generate a Top-50, for example.
Listing 3.3 Fetching Test Measurement Data (AppDelegate.swift demo)
func demo () {
let context = CDHelper.shared.context
let request = NSFetchRequest(entityName: "Measurement")
request.fetchLimit = 50
do {
if let measurements = try context.executeFetchRequest(request) as? [Measurement] {
for measurement in measurements {
print("Fetched Measurement Object \(measurement.abc!)")
}
}
} catch {
print("ERROR executing a fetch request: \(error)")
}
}
Update Groceries as follows to print a sample of the store contents to the console log:
- Replace the demo function in AppDelegate.swift with the code from Listing 3.3.
- Run the application. The console log should show 50 rows of seemingly random measurement objects.
- Examine the contents of the LocalStore.sqlite file using SQLite Database Browser, as explained previously in Chapter 2. Figure 3.4 shows the expected results when viewing the ZMEASUREMENT table, which is the data for the Measurement entity.
)
Figure 3.4 Test data ready for the next parts of this chapter
Close the SQLite Database Browser before continuing.