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
Is your feature request related to a problem? Please describe.
When utilizing aliased fields (our use case is minifying datastructures on our edges to reduce costs), class based discriminators no longer function as intended with payloads that are aliased. The constructor for a Discriminator takes a single str as the parameter for field, which will throw an error when trying to deserialize a payload that has been aliased (or vice versa if you set the Discriminator.field to point to the aliased fieldname. MissingDiscriminatorError gets thrown immediately when calling .from_dict, but before __pre_deserialize__ runs (it has to because each subtype can have their implementation of __pre_deserialize__) so it is not possible to fix it with the hook; similarly __post_init__ is also off the table for the same reason.
Describe the solution you'd like
Ideally, for mashumaro to perform some resolution for discriminator.field if TO_DICT_ADD_BY_ALIAS_FLAG and allow_deserialization_not_by_alias are enabled, or another configuration option/flag if necessary. Alternatively, being able to provide a tuple of the possible field names for the parser to lazily loop through when performing the discrimination.
Describe alternatives you've considered
The alternatives seem to be using a preprocessor to do some operation like:
where the fields are set to the happiest expected path (this would require allow_deserialization_not_by_alias to be enabled). It does not feel appropriate to require a helper function to utilize mashumaro dataclasses around our codebase.
Alternatively, not utilizing the aliases feature on the discriminator field is a viable workaround.
Additional context
The major reason for submitting this request is consistency between human readable formats and aliased formats. The byte difference is small when leaving one field without an alias configuration but that can add up quickly when processing things at scale and it also brings a small amount of "gotcha" or tribal knowledge ("Why does this field not have an alias? Let me fix that real quick... oh no everything broke!"). There is no mention of aliases being incompatible with class based discriminators so at the very least the documentation can be updated to reflect this.
Here are some models and tests that reproduce the error:
Is your feature request related to a problem? Please describe.
When utilizing aliased fields (our use case is minifying datastructures on our edges to reduce costs), class based discriminators no longer function as intended with payloads that are aliased. The constructor for a Discriminator takes a single
str
as the parameter forfield
, which will throw an error when trying to deserialize a payload that has been aliased (or vice versa if you set theDiscriminator.field
to point to the aliased fieldname.MissingDiscriminatorError
gets thrown immediately when calling.from_dict
, but before__pre_deserialize__
runs (it has to because each subtype can have their implementation of__pre_deserialize__
) so it is not possible to fix it with the hook; similarly__post_init__
is also off the table for the same reason.Describe the solution you'd like
Ideally, for mashumaro to perform some resolution for
discriminator.field
ifTO_DICT_ADD_BY_ALIAS_FLAG
andallow_deserialization_not_by_alias
are enabled, or another configuration option/flag if necessary. Alternatively, being able to provide a tuple of the possible field names for the parser to lazily loop through when performing the discrimination.Describe alternatives you've considered
The alternatives seem to be using a preprocessor to do some operation like:
where the fields are set to the happiest expected path (this would require
allow_deserialization_not_by_alias
to be enabled). It does not feel appropriate to require a helper function to utilize mashumaro dataclasses around our codebase.Alternatively, not utilizing the aliases feature on the discriminator field is a viable workaround.
Additional context
The major reason for submitting this request is consistency between human readable formats and aliased formats. The byte difference is small when leaving one field without an alias configuration but that can add up quickly when processing things at scale and it also brings a small amount of "gotcha" or tribal knowledge ("Why does this field not have an alias? Let me fix that real quick... oh no everything broke!"). There is no mention of aliases being incompatible with class based discriminators so at the very least the documentation can be updated to reflect this.
Here are some models and tests that reproduce the error:
The first test will pass but the second will throw:
The text was updated successfully, but these errors were encountered: