0
votes

(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.

2
@DuncanGroenewald, no, but I am afraid of already existing info. Which is in different formatAleksey Potapov
Well if you have renamed the attribute it any data in the old attribute will be lost when the store is upgraded. Be sure to set the options to allow the store to be upgraded to the new version of the model.Duncan Groenewald
@DuncanGroenewald, so the previous data will be removed anyway?Aleksey Potapov
Well if that's what you want then just create a new attribute called SpeedHistory and leave the old one as is or remove it, just don't use it in the new app or copy the data across to the new attribute when the app opens the first time .Duncan Groenewald
@DuncanGroenewald, hmm.. create this in OLD database?Aleksey Potapov

2 Answers

1
votes

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.

0
votes

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.