My CoreData Migration (Test)
A walkthrough lightweight and heavyweight migration
When I worked on
CoreData I was usually able to perform a lightweight migration to a new model version. But whenever it came to a more complex use case I struggled to find a solution.
That is why I wrote this piece.
But first, what’s the difference between a lightweight and a heavyweight migration?
Core Data can typically perform an automatic data migration, referred to as lightweight migration. Lightweight migration infers the migration from the differences between the source and the destination managed object models.
Using Lightweight Migration
Core Data can typically perform an automatic data migration, referred to as lightweight migration. Lightweight…
To me, this means easy use cases like adding and renaming variables or creating new relationships and objects.
Use heavyweight (manual) migration in rare cases when changes to the data model exceed the capabilities of lightweight migration.
Starting with the test of a LightWeight Migration
Let’s start with a simple
CoreData model. We have a person that has a name, a surname, and the information of whether they’re a teacher (as a Bool).
However, we soon realised that this model was not sufficient for our new purpose. The new model changed the variable names and is adding the variable “age”.
Since this modification is done with a lightweight migration we have now finished creating the new model version. But we’ll feel a lot better if we test the migration with the help of XCUnitTests!
Here’s the code to perform this:
ManagedObjectModel and initialise the
NSManagedObjectContex with the
PersistentStoreCoordinator containing the SQLite file URL.
Add some test data for the migration. In this case, it is a person who is a teacher.
ManagedObjectModel that is the migration destination. For the lightweight migration, we have to set the following options:
This is so
CoreData knows it should try an automatic migration.
Then we create the
PersistentStoreCoordinator and add a
PersistentStore. It’s important to use the same URL as we did with the first model version.
We can now test the migration and we can see that the variables have been renamed and “age” has been added.
The HeavyWeight Migration
Since we know whether each person is a
teacher or not we want to split them into
students. To do this, we need to create a new objects
Person(teacher: true) ->
Teacher & Persons(teacher: false) ->
We will do so by adding a new CoreData Model Version 3.
To execute this Migration we will need a Mapping Model and a Custom Migration Policy. You can delete all but one of the Entity Mappings. Now we need to add a Custom Policy for the migration. Make sure to add the project name in front of the Custom Policy class name.
Next, we need the
Check if the entity is a
Fetch the names from the entity
teacher or a
student and add the
Testing the HeavyWeight Migration
Just as with the
LightWeight migration, we will read the old model and create the
Here we add the new elements that should be migrated
Here we migrate to the new model version. Therefore, we need to get the mapping model and create the
MigrationManager with the old and the new model. Then we run the migration with the help of the manager and the mapping model. Then we load the new
Finally, we add some tests to verify that the migration was successful.
I hope that this piece helps you to test your
CoreData Migration code!