I'm working on an app which using core data (one app is already live on the AppStore). OK, now I want to make it fully functional for iOS8 and client also asked me to make a good change in UI and its structure so I started a complete new project and decided to code it my self. Everything works fine, then client emailed me and confirm that, new version of app should store & fetch existing values from the database if existing app will get update. I feel bad here.
I know core data migration is possible ( I read this too, but there's some glitches in my mind about this concept.
As I told, I started a new project though is it possible to add a new version of the model?
Our entities and attributes names are not same. I named it the way I want.
Our model name is same. e.g. Somename.xcdatamodel
My app will update to the existing app on the AppStore.
How I can migrate the existing core data database to the new one?
Is this possible? How?
Any suggestions and help on this would be appreciated.
Note:
I read this question, Core Data Migration: How to delete the Core Data stack? and found that there's no issue if I delete the previous model? What you suggest?
If you need to migrate and keep the existing data, you should read more about writing custom policy Core Data Versioning Guide. Read this guide completely to get to know which category your app migration falls in.
1. Lightweight migration.
2. Or you have to write your own custom policy.
As far as i can tell from the details you provided it looks like it might be a lightweight migration for which you do not have to do anything you can just add a new version to xcdatamodel and mapping models. If not then you have to write your own custom policy and mapping models.
Also make sure you test upgrade properly.
Related
I have finally published my first App, and am now looking to make improvements from user feedback.
The app uses CoreData with existing schema entities and attributes. I am looking to add additional attributes to existing entities, and add some new entities.
My question is, can I simply make changes to the CoreData schema then publish the app's update? Is there any migration process I need to be aware of? What do I need to consider as the impact on existing app users?
I vaguely recall reading many months ago that I should "version control" CoreData? Though I might be completely wrong.
Look into lightweight migration and model versioning, also test, test and test.
https://developer.apple.com/documentation/coredata/using_lightweight_migration
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/Introduction.html
This is also a really good article
https://www.grantgrueninger.com/2020/01/nspersistentcloudkitcontainer-in-production/
I emphasize sending an update with just the core data changes before the code that actually uses the changes to prevent inconsistencies when the user has 2 devices.
I'm new to Core Data migrations. I read a tutorial about light weight migration. The scene is like this:
I created a data model, it is version-1.
So I have to add an attribute in my entity, I did this using a light weight migration. Now the data model is version-2.
Sadly, I need to add another attribute again. I still use a light weight migration to do that, now the data model is version-3.
If my user updates quite often, it is alright. But what if my user has data model version-1, and updates the app directly to data model version-3? Do I need to write code to handle the migration from v1 to v3, or is it handled automatically for me since I used light weight migration?
Your app needs to be able to handle all possible migrations that might happen. If the current version is the third, it must be possible to upgrade all previous versions to version 3.
This doesn't mean you actually have to write code for the migration. If automatic lightweight migration is possible, then it will work, without any custom migration code. Whether that works depends on how the model has changed. If a v1 --> v3 migration is possible with automatic lightweight migration, you can use that. If it's not possible with automatic lightweight migration, you need to handle it yourself. The answer depends only on how similar version 1 is to version 3, and has nothing to do with the fact that there was also a version 2.
In my experience this works automatically. It's fairly easy to test, also, so I would recommend that. Create v1, install app on device, add some data to the app. Create v2, v3, then run app on same device. Does it work?
Also, you need to be careful when writing new app code that you don't assume that the new fields have valid data in them for any existing records in the database at time of upgrade.
I've been searching around and let me get this straight, every time I change the attributes of my entities, I need to create an entirely new version of my model? I understand that the SQLite database is now out of sync with my data model, but can't I just delete the sql files and re-run my simulator? This is what I've been doing, but it doesn't seem to be working.
You are correct, any changes to the core data model must be made in a new core data model version. You can avoid having to do this for development builds by resetting content and settings in the simulator, or deleting the old app version on a device before installing. For store builds though, you must correctly manage your model versions so that user's will have their persistent store properly migrated to a new store with the new model. Versioning is required so that lightweight migrations can be performed, without you having to write custom migration code. If you don't want to version your model, you are bound to writing code to properly migrate your entities. This can be a lot of work and difficult to maintain, you'd rather use lightweight migration and versioning.
(Actually, I don't know how to formulate my question, so in google I found nothing.)
So, the situation: In app in appstore I've the Core Data entity (let's say Weather), one of its attributes is Speed type String. Now it contains single line (e.g. 5 mps), but now I want it to contain an array-like string (e.g. 5 mps; 6.4 mps; ...) also change name from "Speed" to "SpeedHistory".
And I made a new model verison, chose it (it has little checkbox now), renamed the attribute, set "Renaming ID":"Speed" and now: how should I act, to prevent user's of old version data crash?
Could you give me some advice, please?
P.S. Data in Weather Entity is fulfilled by user. And I'm using MagicalRecord.
This is a rather common issue. When you update your model when using core data you have to migrate it. You can follow this tutorial which explains what you should do to fix your issue:
http://www.raywenderlich.com/27657
A lightweight migration is also relatively simple and can be performed safely. You only need to worry when the changes in your model kind of require a change in logic.
Changing the type of a column is something that can't be done with lightweight migrations. If you want to migrate the users' data when they upgrade to your new model version, you'll need to create a mapping model. This process is described in the Mapping Overview section of Apple's Core Data Model Versioning and Data Migration Programming Guide.
I haven't had much success with mapping models, as they seem to be very memory-hungry.
Have you considered adding the SpeedHistory attribute without removing the Speed attribute or setting a renaming identifier? Then in your model class you could override awakeFromFetch:, check whether there's a Speed, and if there is then set the SpeedHistory as appropriate and clear the Speed. You'll migrate the objects one at a time, on an as-needed basis.
I want to add a new attribute to my Core Data model but I'm worried if I do the users data will no longer work, and they'll have to redownload the app. I've had issues before where I change it a bit (though through deletion) and it causes big issues with the app where I need to reinstall it.
How should I go about doing this?
The process is called Core Data Migration: Ray Wenderlich has a great tutorial on it here. If you are just adding a new attribute, it should be (relatively) simple to do an automatic/lightweight migration.