only is not bound by declared and additional fields on serializaton
See original GitHub issueThe only parameter is correctly bound to the fields that are defined in Meta.fields (#183):
class MySchema(Schema):
class Meta:
fields = ('a', )
MySchema(only=('b', )).dump({'a': 1, 'b': 2}).data == {}
Strangely it is not bound to the declared and additional fields:
class MySchema(Schema):
a = fields.Str()
class Meta:
additional = ('b', )
MySchema(only=('c', )).dump({'a': 1, 'b': 2, 'c': 3}).data == {'c': 3}
It would be more consistent if the second example also returns an empty dict.
Issue Analytics
- State:
- Created 6 years ago
- Comments:13 (13 by maintainers)
Top Results From Across the Web
Specify which fields are (not) serialized in ObjectOutputStream ...
PutField lets you specify which (additional) fields are serialized but unfortunately the interface only has a lot of methodes of the form put( ......
Read more >CA2235: Mark all non-serializable fields (code analysis) - .NET
Cause. An instance field of a type that is not serializable is declared in a type that is serializable. Rule description.
Read more >Java static code analysis: Fields in a "Serializable" class ...
This rule raises an issue on non- Serializable fields, and on collection fields when they are not private (because they could be assigned...
Read more >Protocol Buffer Basics: Java - Google Developers
The definitions in a .proto file are simple: you add a message for each data structure you want to serialize, then specify a...
Read more >Serialization with Jackson - Documentation - Akka
The Jackson serializer will ignore properties that does not exist in the class. Add Optional Field. Adding an optional field can be done...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Related to https://github.com/marshmallow-code/marshmallow/issues/698.
There seems to be an agreement on validating
only
, raising errors if names are passed that don’t match a field (be it declared explicitly or added withfields
oradditional
).To be more explicit, both examples in OP would fail with “b is not a valid field for MySchema” or “c is not…”.
I think
exclude
should be treated the same way.(The only use case I can think of that would be broken is when using programmatically defined schemas where it might be easier for the caller to pass a list of fields names to exclude and let the schema just ignore fields that don’t exist. For instance, the caller could pass
exclude=('blacklisted_field', )
to all his schemas without being sure the field actually exists in all of them. But this sounds like an edge case and I’m not convinced it is worth consideration. Besides, it might be doable with a Schema subclass. So I’m happy with an exception being raised.)Would it make sense to validate
exclude
the same way?