-
-
Notifications
You must be signed in to change notification settings - Fork 627
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
RFC: replace load_from and dump_to with a single parameter #717
Comments
I was reading the discussion on PR #174. Just to add some context and see if I understand well (the doc is not always very clear): We have a A Some comments answering the questions:
|
@tinproject, thanks for stating this clearly, in a perhaps less convoluted way than I did. I agree with everything you said. The only I part wasn't totally convinced about is why we need to decouple the schema from the model. I use the schema to decouple API I/O from model objects, but I don't see the need for a schema field with a name that differs from both the model and the API. From an architectural point of view, I mean. From a practical perspective, I just identified a use case. The new parameter sort of overlaps with my_field = Field(attribute='field') would be equivalent to field = Field(key='my_field') but it does not matter IMHO. Keeping both shouldn't be an issue in terms of code maintenance. I'm more worried about the Regarding the name of the new attribute, I think |
One good case to have the option to decouple the model from the schema is when refactor the model, not having to change the schema and the related tests, only the attribute names. Also if you have models with names coming directly from a database, and you want to have different names (more clear) in your schema to use in validations for example. I believe that flexibility, and symmetry on design is well worth. To simplify the code both |
Hmmm, at And I suppose people with enough imagination could come up with use cases where a field's name is changed during execution, or a Field instance is used in several places of a Schema. I'm afraid this simplification is not possible. Too bad, because it sounded nice. Or am I missing something? |
I just pushed a draft (#724). I'm still unsure about the name. I would have liked to avoid Maybe |
This is a great RFC. I really like the idea. I would suggest def dump(self, obj, many=None, update_fields=True, **kwargs):
def load(self, data, many=None, partial=None): I do think it makes sense to drop As such, while something like this "key" parameter is very useful, As an example, suppose I'm building a CRUD HTTP endpoint, and I want to enable filtering ( |
+1 - I could really use this while dealing with a legacy CamelCase schema, in a DRY manner. |
@lafrech Thanks for keeping that up to date. I think |
We use `dump_to` in our schemas, they're deprecating this keyword in favor of another one: marshmallow-code/marshmallow#717 This keeps duffy deployable for now.
We use `dump_to` in our schemas, they're deprecating this keyword in favor of another one: marshmallow-code/marshmallow#717 This keeps duffy deployable for now.
For anyone interested in different keys for serialization/deserialization - here is hack for marshmallow>=3.0.0b8 |
See discussion in #714.
In the general case, dump/load is symmetric and if you have a model field that is exposed with another name, you use the API name in the schema, and specify the model name as
attribute
.dump_to
andload_from
introduce asymmetry, allowing to specify a different key for dump and load:If you want to reproduce use case 1 using these, you need to specify both
load_from
anddump_to
and make sure they match:The flexibility brought by having both
load_from
anddump_to
comes at a price: complexity for the user but also in the code (marshmallow and related libs like webargs, apispec...), potential undefined cases for some weird combinations...Assuming symmetry is not required, a single parameter should be enough. There is however a limitation with
attribute
. It can't be used for APIs where the keys are invalid Python variable names:Currently,
load_from
anddump_to
can be used for this as shown above.The proposal here is to introduce a new parameter to unite them all. Let's call it
key
for now, short of a better name:If we do that, then there is no point in
attribute
anymore (except backward compatibility). So we'd removeattribute
,dump_to
andload_from
.Any objection to this?
Any suggestion for a better name?
The text was updated successfully, but these errors were encountered: