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

define a way to easily provide data_key without breaking the bank #232

Open
mmerickel opened this issue Oct 19, 2022 · 0 comments
Open

define a way to easily provide data_key without breaking the bank #232

mmerickel opened this issue Oct 19, 2022 · 0 comments

Comments

@mmerickel
Copy link
Collaborator

mmerickel commented Oct 19, 2022

A really common use-case I've run into in my codebase is that our raw data schemas use hyphens - thus not mapping directly to a python identifier. In these cases we need to specify data_key and when we do that, we have to break out and define the entire marshmallow field ourselves, losing all the great stuff desert does for us. I'd love to see desert.field, desert.ib, and desert.metadata extended to support data_key= to forward along to the underlying type, as well as potentially other standard field options if applicable. The other two that stand out to me are validate and error_messages. I acknowledge that this is a slippery slope but maybe it'd make sense for those APIs to just forward **kwargs to the underlying field, and potentially to even error on kwargs if a field is passed in. Were there other use cases of kwargs on those APIs that this would conflict with? If so, we could define a marshmallow_field_args arg instead to disambiguate, alongside the existing marshmallow_field positional?

@dataclass
class Parent:
    name: str = desert.field(mm.fields.Str(data_key='userid', required=True))

vs

@dataclass
class Parent:
    name: str = desert.field(data_key='userid')

I'm happy to contribute a PR if I can get some confidence that this will be accepted design-wise.

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

No branches or pull requests

1 participant