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

Behavior with aliases #38

Open
art049 opened this issue Nov 4, 2020 · 1 comment
Open

Behavior with aliases #38

art049 opened this issue Nov 4, 2020 · 1 comment
Labels
question Further information is requested

Comments

@art049
Copy link
Owner

art049 commented Nov 4, 2020

Hello, I'm thinking to enable the aliases on the fields. It would enable a cleaner attribute validation to avoid conflicts between builtin methods and the fields for example (as already done by Pydantic).

The current behavior I'm thinking of:

  • If a field has an alias and no key_name, the resulting document key will be the alias
  • It's still possible to customize the key_name with an alias already set by specifying the key_name kwarg

Do you think some more customization/options would be useful ?

@art049 art049 added the question Further information is requested label Nov 4, 2020
@Extertmin4tor
Copy link

Customization would be very helpful.

Preferred behavior in my opinion:

  • An object creation are possible from dict with alias/field keys, but document creation itself should be regulated using parameter like by_alias , that pydantic's dict method already have.

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

No branches or pull requests

2 participants