Crash on model scheme change

[toshi0383]

If you change type definition of Codable instance, then you get crash immediately by force try.
Maybe Codable is not fully supported?

[AndrewBennet]

If you change the type definition after persisting a value, then the data encoded under the provided key no longer corresponds to a representation of the type which is annoted with the Persisted property wrapper.

I.e., if you go from:

struct MyCodableType: Codable {
    let propertyOne: Int
    let propertyTwo: String

    @Persisted(encodedDataKey: "myPersistedCodableData")
    static var persistedInstance: MyCodableType?
}

to:

struct MyCodableType: Codable {
    let propertyOne: Int
    let propertyTwo: String

    // Adding this new property here:
    let newThirdProperty: Double

    @Persisted(encodedDataKey: "myPersistedCodableData")
    static var persistedInstance: MyCodableType?
}

then the data stored in UserDefaults prior to change cannot be deserialised into a MyCodableType since it lacks the new property. There's a few possible solutions to this:

• Change your encodedDataKey when you change the Codable type definition, and have some migration code somewhere (if necessary) to decode the old type, copy the values into the new type, and persist the new object.
• Change this library to provide an overload of the Persisted property wrapper for the Codable types to behave more cautiously, returning nil when the data could be deserialised. E.g.:

@Persisted(safelyDecodedDataKey: "myKey")
var persistedInstance: MyCodableType?

// If MyCodableType definition is changed after storage, then the property returns nil rather than terminating

What do you think?

[toshi0383]

I prefer the second option!🤩
But further I would rename existing one as "unsafe" and introduce new safe one without safe/unsafe prefix.

// newly added (might need to rename to avoid confusion)
@Persisted(decodedDataKey: "myKey")
var persistedInstance: MyCodableType?

// rename existing
@Persisted(unsafelyDecodedDataKey: "myKey")
var persistedInstance: MyCodableType?

Thoughts?

[AndrewBennet]

Yes, having the safe/unsafe variants as an option sounds sensible. And I agree with your suggestion about the naming - although this does raise the question: should all of the other @Persisted wrappers be considered unsafe? After all, if UserDefaults contains a non-nil scalar value of a different type, there will be a runtime crash at Persisted.swift:l36. E.g., if the following code property has been set:

@Persisted("someKey", defaultValue: 1) var myProperty: Int

and then in a later version it is changed to:

@Persisted("someKey", defaultValue: "hello") var myProperty: String

then accessing the property will cause a crash, since the UserDefaults value under the key "someKey" is not a String (it is an Int). Should these be named "unsafe" too? I feel not. Maybe this difference between namings is acceptable, because changing the type of a property is a less likely use than changing the definition of a type which is used?

I'll mull it over for a bit longer. Let me know your thoughts too.

[toshi0383]

Should these be named "unsafe" too? I feel not.

IMHO I feel yes to this one. If crash is caused by the UserDefaults itself, then it's fine. (I see that kind of almost unavoidable crash in UITableView pretty often.) But if not, the library should not crash. Persisted.swift:l36 should return the defaultValue instead of fatalError ing.

Library design is completely up to you, so it's okay if you want it that way, but then how do you guide a library user not to accidentally use the same key used in past for different type?

// version 1.0.0: added
@Persisted("someKey", defaultValue: 1) var myProperty: Int
... 3 months later
// version 2.0.8: deleted
// @Persisted("someKey", defaultValue: 1) var myProperty: Int
... 6 months later
// version 4.0.0: accidentally added new one with same key
@Persisted("someKey", defaultValue: "hello") var myProperty: String

[AndrewBennet]

You make a good point! I'll see if I can put together a PR sometime soon with these changes.

[AndrewBennet]

(Or I'm happy to review a PR if you'd like to create one)