Support migrations

[sindresorhus]

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.

Defaults.migrations = [
	.Migration(version: "1.2.3") {
		// How to handle it here?
	}
]

I'm open to ideas.

[koraykoska]

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.
Default values can be any Codable type. We would just have to maintain those Migrations in memory and apply them before decoding.

The question is how. Codable and its decoders don't really have an easy way to access or modify parts of the resulting JSON.

[sindresorhus]

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.

[sindresorhus]

I had an idea for this last night. We could give the user a Partial version 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

---

There are some good ideas in this article: http://merowing.info/2020/06/adding-support-for-versioning-and-migration-to-your-codable-models./

[koraykoska]

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> .