Skip to content

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

@mmerickel

Description

@mmerickel

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions