mirror of
https://github.com/JohnEstropia/CoreStore.git
synced 2026-01-14 07:33:28 +01:00
Support for Synchronous Lightweight Migration (adding a new entity) #424
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 @ptrkstr on GitHub (Jan 3, 2024).
Hey @JohnEstropia, thank you for CoreStore ❤️
I am following the Synchronous Lightweight Migration guide from the readme.
My new model has a new entity which is supported by lightweight migration:
This is code that is live (CoreStore 9.2.0):
This is a change in the code to introduce the entity
Cat(no change toDog):Errors when running
CoreData
DataStack.swift:544 calls
coordinator.addPersistentStorewhich triggers the error to console:CoreStore error
Questions
Is this a design decision by CoreStore to not allow synchronous lightweight migration? (my understanding is this is achievable in CoreData directly)
Sample Project
💡CoreStore.zip
@ptrkstr commented on GitHub (Jan 5, 2024):
I was able to create a synchronous version of:
This didn't work with the non-progress function
which caused the following CoreData error:
You can see the code changes for this here:
Which contains:
addStorageon a background threadaddStoragecompletes@JohnEstropia commented on GitHub (Jan 9, 2024):
@ptrkstr Does your update above actually resolve the lightweight migration issue?
@ptrkstr commented on GitHub (Jan 9, 2024):
If by lightweight migration issue you're referring to being able to perform a lightweight migration synchronously, then yes, attached is a video and project (which points to the above branch) demonstrating this.
Given lightweight migration performed synchronously is possible with vanilla CoreData, could it be supported by CoreStore?
💡CoreStore 2.zip
https://github.com/JohnEstropia/CoreStore/assets/11362913/c60508be-13a3-41cf-a5a1-3db8c74657d3
@JohnEstropia commented on GitHub (Jan 11, 2024):
Thanks for creating a demo app! It helped clarify what's going on.
It's been raised before and I just completely forgot about it, so I'm so sorry about the delays.
Core Data actually cannot execute a "lightweight migration" on this model, that is,
addPersistentStore()fails on both the async and sync versions of CoreStore'saddStorage*methods.What does succeed is the proceeding "Inferred Migration", where CoreStore's async method initializes an inferred mapping model and calls
NSMigrationManager.migrateStore()for you. This is not Apple's advertized "lightweight migration" that requires only theaddPersistentStore()call.Admittedly, I never researched in detail what schema changes this "lightweight migration" does succeed at. I guess at this point I can consider lifting this discrepancy for CoreStore's API consumers and just treat
.allowSynchronousLightweightMigrationas something like.allowSynchronousInferredMigrationinstead, but I never supported this from the start because of one reason:addStorageAndWait()from the AppDelegate'sdidLaunchWithOptionsor something like your Demo'sApp.initthat blocks the app's launch process and will increase likelihood to get terminated by the OS's watchdog timer@ptrkstr commented on GitHub (Jan 13, 2024):
Hey @JohnEstropia thanks so much for spending more time explaining this 🙏
I did do a search for this situation and did come across that post but I must have missed that comment.
Your point about memory use in inferred migrations is a good reason to avoid it, I will look into restructuring my application to support async migrations.
Perhaps this is the takeaway from this whole issue 😅
Regardless I will close the issue as CoreStore's API does enforce best practises and it may lead to issues if they are modified to support synchronous inferred migration in a simpler way.
Thank you for being an active maintainer @JohnEstropia, I have sent a one-time sponsorship in exchange for the time you have spent responding to me.