-
Notifications
You must be signed in to change notification settings - Fork 95
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
Inconsistent behaviour of load_instance with nested schemas #400
Comments
I'm not sure what If I understand this right - you should just be able to do: prop = fields.Nested(MySchema(load_instance=False)) Similar to: https://marshmallow.readthedocs.io/en/stable/nesting.html#specifying-which-fields-to-nest |
@AbdealiJK you are able to define a nested schema as explicitly But I am talking about the use-case where you have a schema with a nested schema:
In this case, if you use Right now, I am working around this, by manually setting nested fields:
but it seems like this should be handled by the mix-in, no? |
I see, got it - I recall some similar discussions regarding the I stopped following the thread midway - and don't know the current implementation approach it took |
Thanks, that makes good sense: we very likely would want to support nested |
For anybody who stumbles on this issue, I was able to work around it by using this from marshmallow_sqlalchemy import fields
class Nested(fields.Nested):
"""Nested field that inherits the load_instance attribute from its parent."""
def _deserialize(self, *args, **kwargs):
if hasattr(self.schema, "_load_instance"):
self.schema._load_instance = self.root._load_instance
return super()._deserialize(*args, **kwargs) You may have to tweak it to your specific use case. |
Thanks to this MR, it is now possible to define
load_instance
at the instance level (MySchema(load_instance=False)
).However, as far as I can tell, this setting is not inherited by nested schemas, and there is no easy way to make the nested schema behave like its parent… Resulting in half-loaded schemas (top-level is a dict, with instances underneath).
Could we consider changing that, or is there an obvious workaround that I am missing?
The text was updated successfully, but these errors were encountered: