Core Data migration and coredata migration
Address: http://blog.csdn.net/jasonblog/article/details/17842535
Core Data version migration Basics
Generally, on iOS apps that use Core Data, Data migration caused by Data model changes of different versions is completed by Core Data.
This Data Migration mode is called Lightweight Migration (which may be lightweight for developers). Developers only need to set the corresponding options when adding the Persistent Store, and the others will be delivered to the Core Data:
From the naming, we can see that these two options represent: Automatic migration of Persistent Store and automatic creation of Mapping Model.
Automatic Persistent Store migration is easy to understand, that is, migrating data from one physical file to another, usually because the structure of the physical file has changed.
The automatic creation of Mapping Model is used to migrate the Persistent Store service. Therefore, when the NSMigratePersistentStoreAutomaticallyOption option of the automatic migration Persistent Store option is @ (YES) and the Mapping Model cannot be found, coordinator will try to create one.
For other initialization scenarios, referInitiating the Migration Process.
Since the creation is attempted, there are different results of success and failure. Only when a data Model change is a basic change can a Mapping Model be created successfully, for example, adding a field or deleting a field; required fields are converted to optional fields, optional fields are converted to required fields, and default values are also provided.
Because the Mapping Model may fail to be created, you can determine whether a Mapping Model can be inferred in advance if fault tolerance is considered:
If you cannot create a Mapping Model using the above method, nil is returned for specific reasons.
The above is based on the ability to automatically find the sourceModel and destinationModel of Core Data. If the corresponding two models cannot be found, developers need to manually create NSMigrationManager for Data migration (referUse a Migration Manager if Models Cannot Be Found Automatically).
Version MIGRATION PROCESS
How is the data migration process performed?
First, there are three basic conditions for data migration: You can open the sourceModel of the persistent store, the new data Model destinationModel, and the Mapping relationship between the two Mapping models.
When the following code is called (
AddPersistentStore):
Core Data creates two stacks (source stack and destination stack respectively. For more information, see
Core Data stack), And then traverse the entiing relationship of each entity in the Mapping Model to do the following three things:
1. Based on the source stack, the Core Data first obtains the existing Data, and then creates an instance of the current entity in the destination stack. Only the attributes are filled and no relationship is established;
2. re-create the relationship between entity;
3. Verify data integrity and consistency, and save the data.
Considering that the second step is to re-establish the relationship between entity, we should create all entity objects in the first step and keep them in the memory, for the second step (as a matter of fact ).
After step 2 is completed, all the data is still in the memory (there may be two copies because there are two stacks) and is truly saved after data verification is completed.
In this case, the memory usage is too high, because Core Data does not have a mechanism to clear the response context during the migration process. Therefore, when there is a large amount of data, the App may be killed by the system due to memory shortage during data migration.
In this case, we can customize the migration process.
Custom Data Migration (solving memory problems)
The custom data migration process can be smoothly divided into three steps:
The first step is to determine whether data migration is required:
Step 2: Create a Migration Manager object:
The third step is data migration:
The code shown in the above three figures is no different from lightweight migration in terms of memory usage and cannot solve the problem of high memory peak.
Although Core Data Expert Marcus S. Zarra prefers to use lightweight migration, Apple officially recommends that
Multiple Passes.
For details about Multiple Passes, the official documentation is very concise. For more information, see
This post on Stackoverflow.
In my words, we simply divide the data Model, split a Mapping Model into multiple copies, and then divide it into multiple migrations to reduce the memory peak. This requires a full consideration of the database (or even part of the design may need to be changed), and then put the associated Entity in a Mapping Model (because the association should be established) through a reasonable division ).
New Problems
The above scheme is used to solve the problem of memory peak during data migration. We still need to pay attention to the time and memory consumed by the migration so as to verify the effectiveness of the scheme on the data, and make some necessary changes in user interaction (it is impossible for users to wait for data migration over there ).
Although it can solve the problem of memory peak, but also introduced other problems.
1. Data models need to be divided (and changed), which has certain workload and risks;
2. You need to manually create multiple Mapping models;
3. You need to manually write the Multiple Passes migration code;
4. You need to create a new Mapping Model in each version change, and there are other problems in the Cross-version migration process;
5. when there are multiple data Model versions, you are faced with the problem of cross-version migration. You need to create a Mapping Model for each historical version to the latest Model, or is it time-consuming to maintain only the latest two versions of the Mapping Model (earlier versions are migrated in sequence through the Mapping Model of adjacent versions )?
6. After the data model is re-divided, a simple change to the irrelevant Entity will also cause incompatibility between the entire store and the model. If you need to migrate the data, do you want to consider database sharding?
7. The number of users of such a large Action Service is very small (only a few users will encounter it, or very few), but it is relatively senior (because there are many message records), which hurts...
8. This cannot solve the problem of a large amount of data in a single Entity. In this scenario, you can only manually encode the data for small batch migration;
