I have one app in the store with CoreData model, and i want change entirely the app (remove some garbage, organize, new CoreData model... etc).
So i thinking start over and create new project, what will happen when i try to upgrade the old app that is in the store to this new one? (i'm concerned about CoreData)
thanks a lot
If you change a core data model even slightly, you need to migrate data to the new model:
You can only open a Core Data store using the managed object model used to create it. Changing a model will therefore make it incompatible with (and so unable to open) the stores it previously created. If you change your model, you therefore need to change the data in existing stores to new version—changing the store format is known as migration.
That's from Apple's docs: http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/CoreDataVersioning/Articles/Introduction.html
So if you want users to have their old data in your new version you're essentially going to have to replicate the old core data model in order to extract and migrate the data to your new model. For any release subsequent to that one, of course, you can get rid of the old model.
Related
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:].
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.
Hoping to get some clear advice on this one.
I want to push updates to my app when it is live. I plan to do this by modifying the sqlite that ships with the app and then have the app download it. Easy.
I haven't worked out how actually get the app to see the new data though.. I can overwrite the sqlite in the documents directory, but the app has to be restarted for the new data to be picked up - no good. As a first step I don't mind if modifications to it are lost, but I am really looking for a way to keep any modifications to data, and add/remove entries based on the new sqlite. It will be the entire data-set rather than just the changes.
I am going down this path as the data is quite complex, but manageable through a desktop app based on same core-data model.
Is there a common way, or a way at all to achieve this?
Thanks.
There is no simple way to completely merge to two Core Data stores SQL or other wise.
Maintaining the integrity of the object graph requires that new data be inserted into the existing store via a context using the same model as that used to create the store. In other words, batch adding new data to the store is the same logical process as adding it one piece at a time from UI. You insert NSManagedObject instances, populate them, set their relationships and save them.
In theory, you could write great gobs of code to merge the old and new SQL databases into a new SQL store that Core Data could read. However, that is complex, unsupported and likely to break when Apple revs something in the future.
I would recommend having the app itself download the data piecemeal from the server and then insert the new data into the existing store. It's trivial to send data using something like JSON. Alternatively, you could download a new store, add it to the existing persistent store coordinator and then create clones the new objects in the old store. Then remove the downloaded store from the coordinator and delete the downloaded store file.