8

I have a very simple question related to the usage of lightweight migration and Core Data versioning.

It is well known that when modifying Core Data model one needs to ensure that a transition can occur from the old model to the new one.

For simple changes (like adding a new attribute) lightweight migration is all that is needed. There is lots of information online suggesting that to ensure that all works well one needs to:

  1. Create new model version
  2. Make the necessary modification
  3. Assign the modified version as the new current version

  4. Support lightweight migration with the options:

    let options = [NSMigratePersistentStoresAutomaticallyOption:true,NSInferMappingModelAutomaticallyOption:true]

This approach definitely works well. However, I have also discovered that for simple changes a new model version is not needed. In one of my apps I have already released several updates which included changes to Core Data model (all of them contained additions of new attributes) and lightweight migration was successfully applied without any new model versions.

From my experience it seems that when one modifies Core Data version it is assigned a new identifier of some kind. Then, when this version is launched on the phone which has an older version of this model, lightweight migration is performed without any issues for simple changes.

However, in the light of the fact that every tutorial suggests to create a new model version can someone tell me if I am missing some scenario under which my approach will result in the crash?

Andriy Gordiychuk
  • 6,163
  • 1
  • 24
  • 59
  • 1
    This is my observation too, changed attribute name without creating new MOM version and everything works fine, loading persistent store and lightweight migration was done successfully on my existing data. Did you find any explanation? Documentation doesn't mention this behavior. – El Horrible Mar 18 '18 at 13:03
  • Did you find an answer for this issue? I have exactly the same question! – BlackM Nov 08 '18 at 07:18
  • @BlackM i didn't find the precise answer, but I am using lightweight migration without new model version for many updates now and it works well. So, I guess there is no point in creating new versions for simple changes like addition of new attribute – Andriy Gordiychuk Nov 08 '18 at 10:34
  • 1
    The problem with this approach is when you find out the hard way that a new version was required for your particular "simple change" - unless you're thoroughly testing upgrades before release. Much safer to add a new version for every change. – siburb Jul 16 '20 at 04:11
  • I also observe the same, but when adding a new entity it will surely crash – onmyway133 Oct 15 '22 at 19:54

1 Answers1

0

Hmn... I think you have missed one thing. If your 'new attribute' is mandatory field, then you must have assign a default value of that mandatory field.

note: if you miss to set default value of that non-optional attribute then that attribute will be assigned by a nil value which eventually causes a crash.

Jamil
  • 2,977
  • 1
  • 13
  • 23
  • Such error is not related to Core Data migration. My question concerns migration itself and whether the procedure which I outlined can at any point lead to "the model used to open the store is not the same as was used to create the store" error. The error which you have outlined can only result in the failing of save operation. And this error can occur regardless of whether migration is used – Andriy Gordiychuk May 11 '16 at 18:06
  • http://stackoverflow.com/questions/8881453/the-model-used-to-open-the-store-is-incompatible-with-the-one-used-to-create-the – Jamil May 11 '16 at 18:12
  • it doesn't because the above mentioned question relates to the fact that migration was not implemented. In my case migration is implemented and it works well. However, it misses a step of creating new model version. According to all tutorials I found this step is vital. From my observations it is not vital at all. My question is about whether at some point the omission of this step can lead to errors – Andriy Gordiychuk May 11 '16 at 19:22