-
-
Notifications
You must be signed in to change notification settings - Fork 78
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
Support returning lists of unserialized models #335
Support returning lists of unserialized models #335
Conversation
f7bd362
to
98995e6
Compare
98995e6
to
3708dd3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @jean-edouard-boulanger, if I understand it correctly, your expectation is to return a list like [User(user_id="1"), User(user_id="2")]
directly. I think it's possible but will need to use some tricks.
SpecTree has a construct function called gen_list_model
. I guess you already notice that during this PR. A possible way is:
UserList = gen_list_model(User)
return UserList(__root__=[User(user_id="1"), User(user_id="2")])
Yes this is absolutely correct! I don't particularly like the alternative (using |
Yes, returning a list directly is more convenient. As for the |
e5dd80b
to
2e42762
Compare
2e42762
to
bae8ff9
Compare
With the commit I have just pushed, we're getting much closer to your suggestion:
Couple of examples:Example 1: all item types have the expected/specified type (
|
@kemingy Common validation logic now implemented for both Falcon sync/async implementations (see |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution! 🎉
Thanks for the help merging this @kemingy 🙌 Btw, I have noticed that returning Pydantic root models from views is also not supported. Would you be interested in a fix for this too? |
I'll take #329. You can fix the views if you're interested. Thanks. |
Description
Currently,
spectree
only partially supports validation of list responses. For example:You'll notice in particular that individual entries must currently be serialized before returning or
spectree
crashes. This is inconsistent with the rest of the interface, because it's perfectly okay to return models (without serializing them) - so why not list of models?The change basically updates individual plugins to serialize individual list entries (when needed) before the final response is created. The change is conservative and the above logic is only applied when all of the below applies:
BaseModel
subclass.I have not changed any of the existing validation logic in this case: we still rely on the generated root model for validation.
Change summary:
Response(HTTP_200=List[User])
no longer triggers IDEs / type validation frameworks.