mirror of
https://github.com/JohnEstropia/CoreStore.git
synced 2026-01-11 20:00:30 +01:00
Automatic Lightweight Migration without explicitly create model versions? #401
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 @dwirandytlvk on GitHub (Jan 5, 2023).
HI @JohnEstropia
i would like to ask about lightweight migration in
CoreStorei watch at WWDC video https://developer.apple.com/videos/play/wwdc2022/10120/ that we can do lightweight migration without creating new model version.
Does
CoreStorehas support to do that?Since i have many model/table that will be a tedious process to duplicate previous model into new version and make adjustment in new version model
thank you in advance 🙏
@JohnEstropia commented on GitHub (Jan 5, 2023):
I think you misunderstood. Lightweight migrations allow for migrations between two model versions, without creating a Mapping Model. You still need to keep the models from your past versions.
With that in mind, CoreStore does support lightweight migrations. See https://github.com/JohnEstropia/CoreStore#migrations
@dwirandytlvk commented on GitHub (Jan 5, 2023):
Perhaps i will explain my case study
I have three table
and after i publish my app, i want to update my published app and add 2 column in
UserAuthenticationwhichisCorporateUserandisVerified, so i have to copy my previous CoreStoreObject from v1, into enum v2 and add 2 column intoUserAuthenticationSo my DataStack will be like this
i'm wondering is it possible, to not create
V2and just add new column intoUserAuthenticationinV1?@JohnEstropia commented on GitHub (Jan 5, 2023):
No, it won't be. Core Data needs to know the old model for it to determine if any migrations, including lightweight ones, are needed in the first place.
To save you some maintenance work when adding new versions, I recommend using

typealiases for your model classes, as shown in some examples in the README:This way, you'd only need to refer to
V1orV2in your migration setup code, and your app can use the aliased names forever.@dwirandytlvk commented on GitHub (Jan 10, 2023):
ah i see okay, thanks john @JohnEstropia
May i know what is your suggestion if i have more than 50 CoreStoreObject that separated in several modules how to manage each object based on version?
For example i have 10 CoreStoreObject in
Booking Module, 20 CoreStoreObject inFlight Moduleand 30 CoreStoreObject inHotel Moduleeach CoreStoreObject has relationship each other, so i can not be split into multiple database@JohnEstropia commented on GitHub (Jan 12, 2023):
@dwirandytlvk You're more familiar with your object relationships so this would be up to you, but you have many options:
DataStackdepend on all modules that contain your objectsCoreStoreObjectsubclasses dynamically duringDataStacksetup.CoreStoreSchemadoesn't need static typing, just theEntity<T>instance passed asDynamicEntity: