New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support migrations #29
Comments
Just a few notes as I'm thinking about it... Migrations typically handle two different cases: First if you remove properties which existed before. This is not an issue for us as we save JSON strings and decoding them into a struct which removed a property will not cause any issues. Second is adding properties which did not exist before. For this users would have to provide default values in case the already saved defaults do not include those properties already and decoding into their type would fail. The question is how. Codable and its decoders don't really have an easy way to access or modify parts of the resulting JSON. |
Indeed. That's the difficult part. |
I had an idea for this last night. We could give the user a I also saw an idea about a migrating decoder in the Swift forums: https://forums.swift.org/t/decodable-protocol-conformance-and-generics-how-to-dumb-down-a-conforming-type-to-call-the-right-implementation/29851/5 There are some good ideas in this article: http://merowing.info/2020/06/adding-support-for-versioning-and-migration-to-your-codable-models./ |
It does actually. If the type of the property changed and it is optional,
decoding will not fail but just set it to nil as far as I remember. I can
test this to be sure...
…On Tue 22. Oct 2019 at 06:41, Sindre Sorhus ***@***.***> wrote:
I had an idea for this last night. We could give the user a Partial
version <https://twitter.com/olebegemann/status/1181182254179127296?s=12>
of the original value in the migration callback, where all the properties
are optionals. The benefit of that is that Codable will not throw is some
properties are missing. This does not solve the problem if the type of a
property changed, however.
------------------------------
I also saw an idea about a migrating decoder in the Swift forums:
https://forums.swift.org/t/decodable-protocol-conformance-and-generics-how-to-dumb-down-a-conforming-type-to-call-the-right-implementation/29851/5
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#29?email_source=notifications&email_token=ACWUTTMLVM4BAUAK43QGLOLQPZ753A5CNFSM4I6PMO32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB4QMAQ#issuecomment-544802306>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWUTTMPW2IB3XKZWCPG2X3QPZ753ANCNFSM4I6PMO3Q>
.
|
Sometimes you need to change a structure, for example, add a new property to a struct that is saved in user defaults. You can already do this without migrations by making the property optional, but that complicates a lot of code, and it doesn't work for more comprehensive changes.
I don't have a clear idea of how this would work, but I'm thinking the user would register migrations that run as early as possible at startup or on the first
Defaults
call if before that.I'm open to ideas.
The text was updated successfully, but these errors were encountered: