You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
and I try to load the data. There's no indication of whether each thing should be an A or a B. The new dataclasses are a superset of the old ones, but the schema loader can't load the old data unambiguously. So then how do I load the data to then dump it again with the tagged union?
Use A because it's first
Use B because it's last
Specify with a keyword argument which to prefer
Or, we could tag even non-union fields at dump-time so this situation never comes up. I guess if we want to be compatible with Serde, we can't make this the only option, but it does seem like a situation to keep in mind.
I'd be happy with "user, please never do this" as the answer here, and have the deserializer error out upon finding out that it expected a tagged union but received an untagged piece of data. This is because it should be relatively trivial to write a new serializer/deserializer to port from the old (untagged, only one option) format to the new (tagged union) format, and handle the migration that way.
My feeling is that this might make desert's code simpler as well as set proper expectations with the user: the things that are handled are handled really well, and "magic" schema versioning and migration management is not one of them — and I think that's perfectly reasonable.
Suppose I have
and I dump some data to disk.
Later I change the code to
and I try to load the data. There's no indication of whether each thing should be an
A
or aB
. The new dataclasses are a superset of the old ones, but the schema loader can't load the old data unambiguously. So then how do I load the data to then dump it again with the tagged union?A
because it's firstB
because it's lastOr, we could tag even non-union fields at dump-time so this situation never comes up. I guess if we want to be compatible with Serde, we can't make this the only option, but it does seem like a situation to keep in mind.
Originally posted by @python-desert in #36 (comment)
The text was updated successfully, but these errors were encountered: