I am currently creating an app that requires a large amount of user generated information to be stored in Core Data. When I release a new update of this app, I want to make sure that these users do not lose all of this data.
When I delete my current version from my iPhone, all of the Core Data disappears- will this happen when I create a new update version- does updating cause all of the Core Data to be deleted as the app is replaced? If so, what do I have to do to preserve the data?
I will not be changing my Core Data model between updates, if that changes anything...
Simple question - simple answer, the Core Data is backed up to iTunes/iCloud as part of the iPhone backup, and the users data is also persisted between updates.
You can optionally include the core data to be included in an iCloud sync, this means that even deleting the app and reinstalling it, the data will persist.
If you change your model, you are reasonable for mapping the old scheme to the new one, the data is then transferred via this mapping model when the new update occurs, the previous schemes data will get transferred into the new core data scheme.
Core Data versioning: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreDataVersioning/CoreDataVersioning.pdf
If there is your app in app-store Ver1.0. Updated Ver1.0.1 or higher, CoreData will be maintained. If Core data model changes, although all the previous core data will be maintained.
If there is your app in app-store Ver 1.0. deleting a Ver 1.0. Download it again or download the updated version of, CoreData will be deleted.
If you delete the app, core data will be deleted. To prevent this, using the iCloud synchronization data should work.
refer a following site, iOS How-To : Using Core Data with iCloud
must be you'll read a following Apple PDF: coredata model versioning and data migration programming guide
Related
we published an app in app store, recently added new entities to core data for next version update. At this point we are not worried about migration because all the user's data are stored in our server.
My question is will the update overwrite previous version of core data? if not, how to wipe out the older version?
The short answer is: yes, the update will overwrite the previous version of Core Data.
More precisely, it will migrate to the new data model and therefore adjust the sqlite store, creating new tables and fields as necessary. This version of the sqlite store will be incompatible with old versions. The old version of the sqlite store will be gone.
This implies that when you do a server sync, the applied logic to insert the new information into Core Data also has to be updated to reflect the new model.
I am just about to update one application from me. This app uses Core Data for saving the data, which the user puts in.
Now I want to fix some bugs, which aren't associated with Core Data at all.
What do I have to do that the User gets his data after downloading the Update?
I don't think about Lightweight Migration, because I haven't changed anything.
Do I have to add a new Model Versioning File? - I don't know.
You don't have to to anything. If the model and the data is not updated as part of the update, and you are storing the user's data in the documents directory, then a new version of your app will just carry on using the existing data.
If you haven't changed your Core Data schema at all, then you don't have to do anything. It'll still read the old data files with no problem.
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.
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 am using core data to store favorites chosen by the user. I would like to know that if I send an app update, how can I keep the data of the favorites preserved after the app is updated by the user?
I have read that you could use versioning, but I'm not sure if this the correct method.
Any help will be appreciated! Thanks
If your app maintains the same bundle identifier and you don't copy over the core data store file, you keep it.
If you changed your Core Data model, then you do need to worry about versioning. Depending on changes you may need to write rules for migrating data in the old store to the new format. As you have probably experienced, if you change data structure and do not migrate (or wipe existing data), you crash.