CoreData Version Migration

Core Data Version Migration Basics

Typically, on iOS apps that use core data, data migration from data model changes on different versions is carried out by core database.
This data migration pattern is known as lightweight migration (which may be lightweight for developers), as long as the developer sets the corresponding options when adding the persistent store, and the rest is delivered to core data:



As you can see from the naming, these two options represent the automatic migration of the persistent Store and the automatic creation of the mapping Model.

Automatic migration The persistent store is well understood to be migrating data from one physical file to another, usually because the physical file structure has changed.
The auto-create mapping model is for migrating the persistent store service, so when the auto-migrate persistent store option nsmigratepersistentstoreautomaticallyoption is @ ( YES), and when the mapping model is not found, Coordinator tries to create a copy.
Other initialization scenarios can be referred to initiating the migration Process.

Since you are trying to create, there are different outcomes for success and failure. A mapping model can be successfully created automatically only if the changes to the data model are part of a basic change, such as adding a field, deleting a field, converting a required field to an optional field, converting an optional field to a required field, providing a default value, and so on.

Because it is possible to create a mapping model failure, consider the fault tolerance, you can determine in advance whether the successful inference of a mapping Model:



Using the above class method, if a copy of the mapping Model cannot be created, nil is returned with a specific reason.

The above is based on core data can automatically find Sourcemodel and Destinationmodel, if unable to find the corresponding two model, Developers are required to manually create Nsmigrationmanager for data migration (refer to use a migration Manager if Models cannot be Found automatically).

Version Migration Process

So what is the process of data migration?

First, there are three basic criteria for data migration: You can open the Sourcemodel of the existing persistent store, the new data Model Destinationmodel, and the mapping relationship between the two mapping model.

Take advantage of these three things when calling the following code (addpersistentstore):



Core data creates two stacks (the source stack and the destination stack, which can refer to the Core data stack), and then traverses the mapping of each entity in the mapping model. Do the following three things:
1. Based on the source Stack,core data to obtain the existing information, and then in the destination stack to create an instance of the current entity, only fill the attributes, do not establish a relationship;
2. Re-create the relationship between the entity;
3. Verify the integrity and consistency of the data, and then save it.

Considering that the second step is to re-establish the relationship between the entity, you should create all the entity objects in the first step, and keep them in memory and serve the second step (in fact, as well).

After completing the second step, all the data is still in memory (there may be two, because there are two stacks) that are not actually saved until the data is validated.

This can lead to excessive memory consumption because core data does not have a mechanism to clean up the context of the response during this migration. So when there is a lot of data, the app may be hit by the system when the data migration process is strained by the memory.
For this scenario, we can customize the migration process.

Custom Data migration (resolving memory issues)

The process of customizing data migration is divided into three steps:
The first step is to determine if data migration is required:



The second step is to create a migration Manager object:



The third step is to really take the data migration:



The code shown above in the three images is no different from lightweight migration in memory usage, and cannot solve the problem of high memory spikes.

While the core data expert Marcus S. Zarra prefers to stick with lightweight migration, Apple's official recommendation is to use multiple Passes to address the above-mentioned memory overload.

For multiple Passes, the official documentation is concise and, if necessary, refer to a post on StackOverflow .

In my words, in a nutshell, the data model is divided into multiple copies of a mapping model, which is then divided into multiple migrations to reduce memory spikes. This requires a thorough consideration of the database (which may even require a partial design change), and then the associated entity is placed in a mapping model by a reasonable partition (because of the association).

the new question

Using the above scheme to solve the problem of peak memory in data migration, we still need to pay attention to the time and memory of the migration, so that we can verify the validity of the scheme on the data and make some necessary changes in the user interaction (we can't let the user be silly to wait for the data to be migrated there).

While the problem of memory spikes can be resolved, other issues have been introduced.

1. The data model needs to be divided (and changed), there is a certain amount of work and risk;
2. Multiple mapping Model needs to be created manually;
3. Need to manually write multiple passes migration code;
4. The new mapping Model needs to be created again in each version transition, and there are other issues in the cross-version migration process;
5. Multiple versions of the data model, faced with the issue of cross-version migration, is to create a new model for each historical version of the mapping models, or only the last two versions of the mapping model (earlier version through the adjacent version of the mapping model migrated sequentially , more time consuming)?
6. After the data model is re-divided, unrelated entity simple changes will also cause the entire store and model incompatibility, need to migrate, then consider the sub-Library?
7. Such a large number of users of the Action Service is very small (only a few users will encounter, or very few), but it is more senior (because the message record more), pain ...
8. This does not solve the problem of excessive volume of single entity data, for this scenario, can only be manually coded for small batches of data migration;

CoreData Version Migration