Skip to content
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

@computed_field not showing in json schema #173

Open
Galarzaa90 opened this issue Aug 10, 2023 · 2 comments
Open

@computed_field not showing in json schema #173

Galarzaa90 opened this issue Aug 10, 2023 · 2 comments
Labels
enhancement New feature or request
Milestone

Comments

@Galarzaa90
Copy link

This is something I had also reported to FastAPI and it has been fixed.

The issue is that pydantic now has two serialization modes: input and serialization. Since a computed field's input doesn't need to be validated, it is not present in that mode (which seems to be the default).

This causes autodoc_pydantic to not show these fields in the Show JSON Schema section.

So it needs to be added:

model_json_schema(mode='serialization')
@mansenfranzen
Copy link
Owner

@Galarzaa90 Thanks for reporting this new feature in pydantic v2. This is indeed not supported in autodoc_pydantic yet. Does it make sense to allow the JSON output to be configurable to either choose the input or serialization mode? Or should we aim to simply use the serialization mode as default because it contains the model in its entirety. What is your opinion given your use case?

@mansenfranzen mansenfranzen added the enhancement New feature or request label Aug 10, 2023
@Galarzaa90
Copy link
Author

Galarzaa90 commented Aug 10, 2023

@Galarzaa90 Thanks for reporting this new feature in pydantic v2. This is indeed not supported in autodoc_pydantic yet. Does it make sense to allow the JSON output to be configurable to either choose the input or serialization mode? Or should we aim to simply use the serialization mode as default because it contains the model in its entirety. What is your opinion given your use case?

I was thinking about the same thing, that is a tough question. I believe that serialization is more suitable for general use. But making it configurable using a directive is not a bad idea. But I believe the default should be serialization.

For example, a calculated's property schema (in serialization mode) is marked with the readOnly attribute, indicating that it is not possible to write to it, possibly communicating that it is not something you would use for input.

"isBattleyeProtected": {
    "description": "Whether the server is currently protected with BattlEye or not.",
    "readOnly": true,
    "type": "boolean"
}

On the other hand, the property would simply be omitted in input mode.

@mansenfranzen mansenfranzen added this to the v2.2 milestone Dec 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants