mirror of
https://github.com/JohnEstropia/CoreStore.git
synced 2026-08-28 14:17:23 +02:00
Migrations fails #234
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/CoreStore#234
Reference in New Issue
Block a user
Originally created by @Miggets7 on GitHub (Oct 12, 2018).
Hi John,
I would like to begin with sayring that I absolutly love CoreStore! It's an awesome project and very nice to use.
I'm having trouble though migrating my models. I'm using v5.3.1 and this is the error log:
And this is initialization code:
And the model code:
This used to be the initialization code before(on V5.0):
Can you tell why it isn't working?
@JohnEstropia commented on GitHub (Oct 14, 2018):
I am not sure but I'll throw out some ideas.
First, your
versionLockfor V2'sTapRegistrationseem to be the same with V1, which shouldn't be the case.Second, check your usage of
String(describing: Task.self). I don't recommend using non-static strings for entity names because they will break if you refactor your types.If none of those are the issue, I'm afraid this may be caused by your initialization of
dates. (I haven't proved this but I wouldn't be surprised if it was the cause)The
initial:argument here should be a statically reproducible value (e.g.Date.distantPast), notDate(), which creates the date instance during the time the code was run.@scogeo commented on GitHub (Oct 15, 2018):
I'm new to CoreStore myself, but I hit a similar issue when using synchronous migration with
CoreStoreObjects. Try switching to the asynchronousCoreStore.addStorage()call instead and see if the problem goes away for you.I still see get the Core Data error logs on the console, but the migration does proceed correctly. I just chalked those up to spurious logging due to opening an out-of-date store prior to then beginning migration.
@Miggets7 commented on GitHub (Oct 15, 2018):
@JohnEstropia The
versionLockforTapRegistrationis the one I got from the output of CoreStore itself. So maybe there is a bug there?I've changed the
String(describing: Task.self) to static strings.And I've changed the date code to:
And still I'm getting those errors.
@scogeo I've tried with the asynchronous
CoreStore.addStorage()call but still the same results. A simple call likeCoreStore.fetchAll(From<TaskDBModel>())fails. It returnsnil@JohnEstropia commented on GitHub (Oct 15, 2018):
@Miggets7
Can you try commenting out the
versionLockarguments for both V1 and V2 and check if the hashes are the same?@Miggets7 commented on GitHub (Oct 15, 2018):
@JohnEstropia These are the
versionLockresults:@JohnEstropia commented on GitHub (Oct 15, 2018):
@Miggets7 Oops, sorry I've been misreading the entities. The TapRegistration didn't have attribute changes so the same hash should be fine.
Couple of things I'd like to clarify:
Is
error setting up storage:actually being reached here?Also when you tried to use the asynchronous
CoreStore.addStorage()method, were you getting a.failureresult from the completion block?@Miggets7 commented on GitHub (Oct 15, 2018):
@JohnEstropia
It seems to be working now with the
CoreStore.addStorage()call. It does throw an exeption in NSPersistentStoreCoordinator+Setup.swift here:But it retuns a success call. It seems the data also seems right and running tha app a second time doens't throw any errors. But the completion still return an error object:
Right now it seems I can use this without any problem, so I guess this issue could be closed?
@scogeo commented on GitHub (Oct 15, 2018):
Just a brief followup to the above comment after some brief investigation on my own prototype. You can suppress the Core Data log messages caused by the throw from the call to
addPresistentStorementioned by @Miggets7 by explicitly declaring a simpleCustomSchemaMappingProvider. This will cause a different code path to be taken and avoid the throw and error logs during migration.In this example, something like this should work:
@JohnEstropia commented on GitHub (Oct 16, 2018):
Ah, I see. There is actually a quirk in lightweight migrations where it fails in
addPersistentStore(), but succeeds when using the inferred mapping model that it should have used internally inaddPersistentStore(). You'll find that logic here:I'll look for a way to silent these error logs in this case.
@scogeo Thanks for the suggestion to use
CustomSchemaMappingProvider. While this would work for your data, there is a tradeoff in memory use here as lightweight migration uses batched SQL queries internally as much as it can, whileCustomSchemaMappingProviderrecreates all objects one by one. If you have small data it should be more or less the same. (On a separate note, if your models are expected to succeed with an inferred mapping, you can omit theCustomSchemaMappingProvider'sentityMappingsargument)@scogeo commented on GitHub (Oct 17, 2018):
@JohnEstropia thank you for looking into the problem further, it would be nice to resolve it so I can use the implicit lightweight migration without any errors in the console logs.
Really enjoying CoreStore so far though!
@JohnEstropia commented on GitHub (Dec 5, 2018):
I'm closing this issue now, thanks for all the input.
To future developers who would hit this issue, please note that "lightweight migration" somehow has two types in Core Data: one that would succeed synchronously, and one that needs to run an
NSInferredMappingModel, which means synchronous migration would not work. I have added a new errorCoreStoreError.asynchronousMigrationRequired(localStoreURL:NSError:)thrown fromaddStorageAndWait()which would indicate this case.