This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Pydantic __root__ model - incorrect handling #911
Comments
If anyone wants to submit a PR to fix this I'd be happy to review it. (I think it's worth handling this properly.) |
For now created issue for |
I wouldn't recommend using But in FastAPI, everywhere you can use a Pydantic model you can also use what would be the (arguably?) most "Pythonic" way, using
Given that, as it's still valid Pydantic, I would be happy to support it if someone wants to add a PR with it (as @dmontagu says). |
@tiangolo I understands that |
@tiangolo Supporting pydantic root types would allow a single validator (defined in the wrapper class) to be run on all objects of a certain type- otherwise, the validator must be specified in each object that has a child of that type (as far as I can tell- I'm new to fastAPI, please let me know if there's a better way). |
as @sidmani also mentioned, I'm running into wanting the ability to be able to say: pydantic_list_as_root.dict() and the above output a dict. Rather than having to manually loop through my However, I do appreciate what @tiangolo is trying to achieve by keeping things as pythonic as possible, but I would imagine that many if not all FastAPI implementations heavily rely on Pydantic for defining schemas. Therefore, I think it would be a great idea to embrace all/most of its capabilities. |
Yeah, I would be happy to support it if someone wants to add a PR with it. |
This should be fixed in #1524 by @patrickkwang 🎉 🚀 Available in FastAPI I'm re-opening this to let the original issue author confirm and close it directly 😄 |
Assuming the original issue was solved, it will be automatically closed now. But feel free to add more comments or create new issues. |
When a custom root type is used together with a nested model, FastAPI does not seem to export the nested model. For example Might it be better if Pydantic was offered on an opt-in basis? |
@snow6oy You should create another issue since the original issue has been resolved (and I am not entirely sure if this is a Pydantic or FastAPI issue) or no one will pay attention to the reply to a closed issue. |
The fix in #1524 is not working for me as I'm using multiple levels of nested models with custom roots. This causes an error in Its's an easy fix though I'm not sure if it renders #1524 redundant? PR here: #4428 Temp fix for those in a hurry:
|
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Describe the bug
https://pydantic-docs.helpmanual.io/usage/models/#custom-root-types
Pydantic allows to create models with only
__root__
field. In such scenario the model behaves as transparent wrapper for this single type.When such model is used in response (request also?) fastapi does not treat it correctly and renders it as object with
__root__
field.Object is treated correctly by pydantic itself.
To Reproduce
Expected behavior
The response should be:
but at the moment is:
Screenshots
N/A
Environment
Additional context
N/A
The text was updated successfully, but these errors were encountered: