I've done a custom Core Data migration several versions back when doing some structure changes in my app. (So created a new model version, and a mapping model with custom policy class).
Now, I want to do some more changes. So I've created another model version. Now, I'm not sure whether I need to create another mapping model for this change? If I do, will core data just figure out the appropriate one to use based on the users version?
Will I also need to create another custom policy class, or can I somehow add the new logic to the first one?
Lastly, will I need to add any logic for migrating from the original database straight to the current database? Or will core data figure that out for me, and migrate to the median version first, and then to the current version when a user loads an app version with the original data structure?
Thanks!
I guess the answer to whether or not you need to create another mapping model is... it depends. See Apple's docs here (specifically comments on lightweight migration): https://developer.apple.com/library/ios/documentation/cocoa/Conceptual/CoreDataVersioning/Articles/vmMigrationProcess.html#//apple_ref/doc/uid/TP40004399-CH6-SW1
Depending on your model changes, you may use "The Default Migration Process". When calling addPersistentStoreWithType:configuration:URL:options:error:, use the flag NSMigratePersistentStoresAutomaticallyOption.
Also, I'm sure that unfortunately you need one mapping model for each possible migration. If you have 3 models, you'll have to implement: 1 to 3 and 2 to 3. Core Data is not smart enough to do the intermediate steps automatically :(
Related
I already have an app in the app store. I want to do an upgrade. My local data store has changed, with an extra table, and with a few fields added in the existing table. I want to retain the data in the old tables. How would I go about doing that? Could someone point me to tutorials that handle that kind of change?
Assuming you're using SQLite: Use a new database with a different name for your update. On startup, check for the table with the old name, copy the data you want, and delete it when you're done.
CoreData has it's own update data which may or may not work for you. You should look into how to change the data model.
Check out Apple's docs on migrating a core data instance. They make it super easy for 90% of the cases. The basic idea, is you break you xdatamodel into versions, so it has a path for migration
Here's a tutorial that might help you Core Data Migration
I am new to core data, can anyone let me know the difference between Versioning and Data migration. When we do versioning and when we Data Migration?
Versioning is used just like versioning on apps to indicate different evolving variations of the same basic code except in Core Data the code evolving is the data model i.e. the entities, entity properties and relationships defined in the .xcdatamodel file.
Migration is what you perform on the end user's existing data in the persistent store in order to format/structure the store to work with the new version of the data model.
It works like this:
You release version 1.0 of your app which as a data model with a version of 1.0 as well. End user then use your app and save their data in a persistent store formatted/structure using your data model 1.0.
Then you release version 2.0 of your app and you make changes to the data model in the process e.g. you change a property name, add a property or add an entity. You would version the data model as well to something like 2.0 (the actual version names are arbitrary.) You then provide for either automatic or manual migration such that the end user data in the 1.0 persistent store file can be reformatted to the data model 2.0 format.
Every change you make to a Core Data model results in a new version. EVERY change.
Core Data has no concept of one model being newer than another though, it just knows they are different. Core Data will not use a store (database on disk) created by a model version different than what you have.
That's where Migration comes in, which is simply a process to tell Core Data how to get from one model to another with the data stored in a database made by a particular model. Core Data can try to guess (automatic migration) which for simple changes may work fine, but you can create more complex migrations by hand that carefully pluck data out of one model version and place it in a database of a newer model version.
When do you create a new model version? After you ship an application with a Core Data model to the App Store, you should immediately create a new model version for changes so the original model version that you can create a migration path for people who have the App Store version to a later version.
When should you create a migration? Basically any time you ship a new version to the store, you need to figure out a path from any earlier model that was in the store (and thus may be on someone's phone) to the latest data model version. As noted, if the changes are simple you can use an automatic version, but always test (keep each app store release accessible to build from so you can test out loading an older version then migrating to a new one).
By the way, an acceptable plan is simply to delete the existing database if the model has changed at all, as long as you can put anything the user did back in the database in some way (or if the user never put anything in at all, as in a caching database).
I have the older version of the core data model of the released app. Now, in the next version of the app, I am migrating the core data model to new model. Is there a way to get the attribute values from the old model before actually migrating to the new version of the model or is there possibly a way to know if the migration is to be occurred.
When you migrate, Core Data actually moves existing values for you. If you're doing a relatively simple migration, such as adding or removing some properties, Core Data does its best to make the move as seamless as possible. In many cases, you won't need to make any changes other than set your new model. See my answer here for more.
Yes, it is possible.
To get the attribute values from the old model you'll need to create custom entity migration policies (NSEntityMigrationPolicy subclasses). Then in -createDestinationInstancesForSourceInstance:entityMapping:manager:error: you'll receive source instance, and it is completely up to you how to create destination instances from source instances.
There is a method to check if a given store is compatible with store coordinator model: -[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:].
I have set up and app which has pre-populated data that copies the database to the project's store. Using the 'CoreDataBooks example' method:
Any way to pre populate core data?
For application upgrades, I want to add more data to the database but I don't want to change the existing database since new user data is stored there?
What's the best way to do this?
I'm thinking I would create a new versioned managed object model (I'm not sure if you can add a new MOM version if nothing in the schema actually changes), for new versions, read the currently running MOM version, migrate the MOM to the latest version and manually add the new records in the code that have not been added since the currently running MOM version.
It seems a bit tedious to manually add new records in the code. Does that sound right or is there a more elegant way to add this new data?
Thanks!
If you change the managed object model itself e.g. add a new entity or change an existing attribute, then you need to use migration to update the existing persistent store. See the Core Data docs for details on migration.
If you just want to add new data, then you don't have any choice but to do so "manually."
Remember, Core Data is an object graph management system, not a database. An object "graph" is a "web" of interrelated objects so the only way to add data to the graph is to create new objects and set their relationships. It's not inefficient, it just the way it works.
I am working on an iphone application that uses sqlite to store application and user data.
This is the first version of the application and I wonder what I need to do to prepare for the future versions of the app.
Is this enough?
1. Make sure app version is correct in the XCode Project settings
2. Add a version number in sqlite file so that it can be read later
Lets simulate the next update!
1. New version of the app is downloaded to the device
2. The app reads the version number stored earlier in a sqlite table/field
3. App knows that application data has changed so it needs to update the sqlite and also
it wants to retain the user data (in app favorites & Notes).
4. Schema has not changed so it starts to insert the new application data into some tables.
5. It does not touch the user data tables
6. It updates the version number of the sqlite db.
Have I missed something that will come back and bite me when it is time for update?
So, when you develop an application that uses Core Data you start defining a Core Data Model. Each model will have its own version. You start creating the first and unique version of your model. You can find all the required, detailed, info at the official Apple Core Data Model Versioning and Data Migration Programming Guide
You should not handle database versioning through custom fields set in the database itself, use model versions instead via your Xcode project.
When updating the application, if you do not change the model version you do not have to worry about anything, since the database hasn't been touched. Every new update that do not change the model will require no effort from you.
If you need to update your model for the next update you have to do this:
Create a new model version
Set the new model version as the active version
Modify the model according to your needs
Here comes the interesting part. Your application will handle the migration between the models in two different ways: the simple way and the hard way.
Automatic lightweight migration
Following Apple's official documentation about Core Data Model Versioning and Data Migration, if your model has been slightly changed you can ask the application to perform an automatic lightweight migration. This step will update the existing database to the new version if these requirements are met:
Simple addition of a new attribute
A non-optional attribute becoming optional
An optional attribute becoming non-optional, and defining a default value
The lightweight migration process will handle the appropriate required step to migrate from one model version to another, if possible
Mapping model migration
If you can't perform an automatic lightweight migration you will have to manually define the step to update
the model versions to the new one, using Mapping Model Objects. These objects will define what the application has to do to migrate from model version x to model version y.