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
Extra allOf keys in translation of Unions to OpenAPI schema when Field is used #1209
Comments
Thank you for the response @samuelcolvin . It's unfortunately going to be at least a couple of months before we can delve into the pydantic source code and attempt a fix. If anyone else is able to tackle it in before then, it would be a huge help. And, if other users experience this same issue, hopefully they will find this post and see that they can use |
Given that a length-one-allOf is always a no-op, this branch doesn't actually do anything and skimming the history back to d73aa1b it looks like it has never been necessary (except for the test checking that the result contains So it's a good first issue to unconditionally |
@tiangolo I guess you first implemented this, any idea why it's there? |
Bug
Output of
python -c "import pydantic.utils; print(pydantic.utils.version_info())"
:Description
My teammates and I debated this for a bit but we're fairly confident that we're experiencing a bug, though it could just be a misunderstanding of how the translation to OpenAPI schema is intended to happen. We can at least say that we couldn't find any other issues on this github addressing it or samples in the docs about our case.
Specifically, when we run the following sample:
... we get the expected result:
However, when we change
TestClassC
to be the following:... we get the following:
Take particular note of the additional
'allOf'
keys under the'properties'
We get the same additional
'allOf'
keys if we changeTestClassC
to be the following:Right now, we're using a workaround with the
schema_extra
capability to get rid of these extraallOf
keys but this seemed a bit hacky to us. If theseallOf
keys are the result of a bug, we're happy to provide more test cases that trigger it if that would help. Or, if there's a better way to get rid of it these extra keys that we overlooked, we're happy to help documenting it in any way that we can so others like us don't get confused. Thank you for taking the time to read this issue and for the incredibly useful package!The text was updated successfully, but these errors were encountered: