- Changing one property will cause a migration
- Renaming a property will be "guessed" at via lightweight migration as a deleted property and then an added property; effectively deleting the values in the property.
I would not recommend a heavy migration ever; it is just too expensive. It is frequently faster to just export to another format and then read it back in.
I would consider not renaming the property but just adding the new property and then in the -awakeFromFetch
move the data from the old property to the new one.
Or don't rename the property, what is the code reason for the rename?
Update 1
Yes, you can make a decision on migration. To do that, you ask the store if it needs to be migrated. By calling -[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:]
you can determine if a migration is needed. From there you can then determine the file size and make your decision.
However, I would not do a custom migration. There are other options:
If you really need to rename the property, consider this:
- Check for a migration situation
- Migration to an intermediate version where the new property name is added.
- Walk your data and copy the values from the old property to the new
- Migrate to the final model where the old property is removed.
I am willing to bet that this will be faster than a custom migration and it will consume far less memory since only one copy of the data is resident.
I really don't like heavy weight migrations on iOS :)
Update 2
Thanks to the comment by Alexei Kuznetsov; you can set the Renaming ID on the property you are going to rename to the original name of the property and lightweight migration should migrate the data correctly. Naturally I recommend testing this to make sure there are no surprises.