#100 (comment) shows one workaround right now but the problem with it is that it requires defining the metadata at the location where the class is used, not where the class is defined.
It would be preferable many times to define the metadata on the class itself.
@desert.meta(unknown=marshmallow.EXCLUDE)
@dataclass
class Child:
name: str
@dataclass
class Parent:
name: str
dummy_list: List[str]
children: List[Child]This is a lot less error prone in situations where I know that the Child schema might evolve and I want to define directly on it the intent that I don't want my deserialization to break when new fields are added.
Arguably the proposed desert.meta is ambiguous with the existing desert.metadata API so open to suggestions on naming as well...
I'm happy to contribute a PR if I can get some confidence that this will be accepted design-wise.
#100 (comment) shows one workaround right now but the problem with it is that it requires defining the metadata at the location where the class is used, not where the class is defined.
It would be preferable many times to define the metadata on the class itself.
This is a lot less error prone in situations where I know that the Child schema might evolve and I want to define directly on it the intent that I don't want my deserialization to break when new fields are added.
Arguably the proposed
desert.metais ambiguous with the existingdesert.metadataAPI so open to suggestions on naming as well...I'm happy to contribute a PR if I can get some confidence that this will be accepted design-wise.