mirror of
https://github.com/JohnEstropia/CoreStore.git
synced 2026-01-11 20:00:30 +01:00
Automatic Lightweight Migrations Unsupported? #52
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 @colinmorelli on GitHub (Apr 26, 2016).
Apologies if I'm missing something here and there's a clear option I can add to support this behavior, but it looks like CoreStore doesn't automatically perform lightweight migrations. While introducing a change that simply added a few columns to an existing model, restarting the application results in error code 3 (MappingModelNotFound)
I don't believe I should need a mapping model for this change, but I don't see any capability of adjusting that behavior.
@JohnEstropia commented on GitHub (Apr 27, 2016):
You don't need a mapping model for lightweight migrations, but you do need to satisfy two conditions to tell CoreStore to do migrations, regardless if lightweight or not, for you:
1.) Declare the migration chain of versions when you initialize your
DataStack:2.) Use the asynchronous
DataStack.addSQLiteStore(....:completion:)method variants instead of the synchronousDataStack.addSQLiteStoreAndWait(...)methods.@colinmorelli commented on GitHub (Apr 27, 2016):
Ah, didn't realize that was required for lightweight. I guess that leads to the next question: does this mean you have to explicitly create model versions even when performing lightweight migrations? Definitely best practice for a released app, but it seems like it could hinder development (albeit slightly).
I'm fine with creating new versions if that's the best way to go about it, it's not really a tedious process. But it would be nice to be able to support lightweight migrations without new model versions (as is the case with addPersistentStoreWithType:configuration:URL:options:error using the NSMigratePersistentStoresAutomaticallyOption option).
Also, excellent job with this library. It makes core data work exactly the way I want it to (read: it makes it not suck to work with).
@JohnEstropia commented on GitHub (Apr 27, 2016):
A small tweak with the
MigrationChainlogic can probably let you do this, but I'm not sure if it's OK to encourage it. If you have version A that can migrate lightweight-ly to B, and B to C, it does not guarantee that A to C can as well.Keeping a history of your models also lets you keep track of the state of your users' existing stores so you can debug problems later on.
Thanks for the feedback, though. I'll close this issue but if you have any other questions feel free to ask :)
@JakeSteam commented on GitHub (Jan 3, 2018):
Just a follow-up note for anyone who finds this looking for a simple transition guide: Step 2 in John's comment above is technically optional, will just give users a rough time.