I am releasing a Core Data based app and wondered what I need to consider if, in an update later down the line, I need to change the model.
How do I move existing user data on the device from the old data model into a new updated model?
Thanks
Generally, you'll have to consider nothing now but as soon as you change your data model, you'll have to employ Core Data's model migration tools. Read the Core Data Model Versioning and Data Migration Programming Guide.
Related
My core data store in the previous version to my app is different to the current one in the following ways:
Attributes missing
New attributes
Attributes which need changing
New entities
New relationships
Attributes which need moving between entities
How should I go about migrating my data? What I had in mind before looking into this was that I could just write code that could take the data from the previous model and put it in place in the new model.
I think the Core Data Model Versioning and Data Migration Programming Guide will cover these issues in some detail.
I would like to update my app, but I have completely changed the data structure, so is the Core Data model entirely different. Now, the data in the app does not have to be preserved, but you can't just update the app with this new model as it will crash.
What is the best way to update my app?
You need to version the core data structure. Use this guide
http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/CoreDataVersioning/Articles/Introduction.html
If you have a completely new data model you might look into having a new database persistent-store/db file and run a merge function if the app can find an old database.
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:].
My iPhone app's core data model is changing and I have a custom mapping model and an NSEntityMigrationPolicy for one of my objects. However, I am worried that some of my users will have thousands of objects in their core data base, are there any best practices for either making the migration as efficient as possible, or conveying to the user what's going on when they load the new update which will try to migrate their data?
You need to warn the user that the app needs to update the data store and you should probably provide a "working" dialog so it doesn't look like the app has hung.
However, the migration is very efficient because it's really just changing the mapping on the store. It doesn't have to actual instantiate all the existing managed objects, it just changes the field names in the store. That can get complex itself in rare cases but most of the time it's barely noticeable.