Skip to content
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

Tags for non-union fields #93

Open
python-desert opened this issue Mar 10, 2020 · 2 comments
Open

Tags for non-union fields #93

python-desert opened this issue Mar 10, 2020 · 2 comments
Labels
enhancement New feature or request

Comments

@python-desert
Copy link
Collaborator

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

Originally posted by @python-desert in #36 (comment)

@altendky
Copy link
Member

In general, this sounds like schema versioning/change/migration management.

@obi1kenobi
Copy link

obi1kenobi commented Mar 10, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants