mirror of
https://github.com/JohnEstropia/CoreStore.git
synced 2026-01-11 20:00:30 +01:00
Progressive Migration inquiry #127
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dwkyuen on GitHub (Mar 22, 2017).
I'm relatively new to the CoreStore framework and have a question about the progressive migration system: my project is set up so that I've got a TestModel.xcdatamodel with three versions: "TestModel.xcdatamodel", "TestModel1.1.xcdatamodel", and "TestModel1.2.xcdatamodel". Each model contains one entity "Person", with one string attribute. In "TestModel.xcdatamodel", the attribute is "name", in "TestModel1.1.xcdatamodel" it is "firstName", and in "TestModel1.2.xcdatamodel" it is "givenName".
I've initialised the default stack as follows:
CoreStore.defaultStack = DataStack(modelName: "TestModel", migrationChain: ["TestModel", "TestModel1.1","TestModel1.2"])
I'm trying to test a progressive migration from "TestModel" to "TestModel1.2" to see how CoreStore handles the changing attribute name from "name" to "givenName", as well as see if I can create a new entity while in 1.2. When I run it, I switch the current version to the "TestModel" first to create the entity with the old naming. After this is done, I switch the current version to "TestModel1.2". I receive this warning: "The MigrationChain leaf versions do not include the model file's current version. Resolving to version "TestModel1.2"" and are wondering what the "leaf" version is, as well as what "leafmost" in the documentation refers to. When I attempt to create a new entity "Person", it also complains about an unrecognised selector.
In short, I am wondering how the progressive migration works: I am aiming to create some entities in an older version, then use progressive migration to update the model a few versions ahead, and then continue creating new entities in the newer model. Any help would be appreciated.
@JohnEstropia commented on GitHub (Mar 23, 2017):
I'm not sure what you mean when you say
Do you mean the "Current Version" in the xcdatamodel file?
CoreStore will ignore the xcdatamodel's current version if you specify a
migrationChainargument to theDataStack. (It's mentioned in the README as well: https://github.com/JohnEstropia/CoreStore#progressive-migrations)So when you tested your migration, you were actually already working on "TestModel1.2" each time.
If you want to see how your entities behave for each version, you'll need to modify the
migrationChaineach time you run.As for how CoreStore handles changing attribute names, well, it doesn't. But Core Data does, so if you have implemented the attribute rename via Core Data's standard methods (the xcdatamodel file or NSEntityMigrationPolicy subclasses) then you will get the same behavior as before you used CoreStore.
@JohnEstropia commented on GitHub (Mar 23, 2017):
By the way, "Leafmost" just means the final version in the MigrationChain. I understand it's a weird terminology when you use a version array as the leafmost is just the last item, but when you use something like
The leaves here are v3 and v4, but v3 will propagate to v4 so the "leafmost" is v4.
@dwkyuen commented on GitHub (Mar 23, 2017):
Yes, I'm referring to the current version, and thanks for clearing up the leafmost term. With the clarification, I'll give things another try and see if it makes a difference: I assumed that CoreStore meant we didn't need to define the renaming identifiers. If I'm not mistaken, adding renaming identifiers should fix things. Thanks!
@JohnEstropia commented on GitHub (Mar 24, 2017):
Yes, the renaming identifier should tell Core Data to handle this for you. I'll close this issue but feel free to ask if you have further questions :)