desert
desert copied to clipboard
Tags for non-union fields
Suppose I have
@attr.dataclass
class A:
color: str
@attr.dataclass
class C:
things: typing.List[A]
and I dump some data to disk.
Later I change the code to
@attr.dataclass
class A:
color: str
@attr.dataclass
class B:
color: str
@attr.dataclass
class C:
things: typing.List[typing.Union[A, B]]
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
Abecause it's first - Use
Bbecause 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.
Originally posted by @python-desert in https://github.com/python-desert/desert/issues/36#issuecomment-596873343
In general, this sounds like schema versioning/change/migration management.
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.