Enhancement: Allow Parameter(schema_extra=...) / ResponseSpec(schema_extra=...)
#3022
Labels
Enhancement
This is a new feature or request
Comments
|
As mentioned in #3018 (comment)
I guess |
tuukkamustonen
changed the title
Parameter schemaParameter(schema_extra=...) to extend/customize the generated OpenAPI schema
tuukkamustonen
changed the title
Parameter(schema_extra=...) to extend/customize the generated OpenAPI schemaParameter(schema_extra=...) / ResponseSpec(schema_extra=...)
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 14, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 14, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 14, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 14, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 14, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 14, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 14, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 14, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 15, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 15, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 15, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 15, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 15, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
provinzkraut
pushed a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 16, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
provinzkraut
pushed a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 16, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 17, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 17, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 18, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
tuukkamustonen
added a commit
to tuukkamustonen/litestar
that referenced
this issue
Mar 18, 2024
…3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response).
cofin
pushed a commit
that referenced
this issue
Mar 19, 2024
* feat: Support `schema_extra` in `Parameter` and `Body` (#3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response). * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> --------- Co-authored-by: Jacob Coffee <jacob@z7x.org>
JacobCoffee
added a commit
that referenced
this issue
Mar 22, 2024
* feat: Support `schema_extra` in `Parameter` and `Body` (#3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response). * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> --------- Co-authored-by: Jacob Coffee <jacob@z7x.org>
provinzkraut
pushed a commit
that referenced
this issue
Mar 29, 2024
* feat: Support `schema_extra` in `Parameter` and `Body` (#3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response). * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> --------- Co-authored-by: Jacob Coffee <jacob@z7x.org>
provinzkraut
pushed a commit
that referenced
this issue
Mar 29, 2024
* feat: Support `schema_extra` in `Parameter` and `Body` (#3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response). * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> --------- Co-authored-by: Jacob Coffee <jacob@z7x.org>
provinzkraut
pushed a commit
that referenced
this issue
Mar 30, 2024
* feat: Support `schema_extra` in `Parameter` and `Body` (#3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response). * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> --------- Co-authored-by: Jacob Coffee <jacob@z7x.org>
robswc
pushed a commit
to robswc/litestar
that referenced
this issue
Apr 2, 2024
…3204) * feat: Support `schema_extra` in `Parameter` and `Body` (litestar-org#3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response). * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> --------- Co-authored-by: Jacob Coffee <jacob@z7x.org>
JacobCoffee
added a commit
that referenced
this issue
Apr 5, 2024
* feat: Support `schema_extra` in `Parameter` and `Body` (#3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response). * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> --------- Co-authored-by: Jacob Coffee <jacob@z7x.org>
JacobCoffee
added a commit
that referenced
this issue
Apr 5, 2024
* feat: Support `schema_extra` in `Parameter` and `Body` (#3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response). * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> --------- Co-authored-by: Jacob Coffee <jacob@z7x.org>
provinzkraut
pushed a commit
that referenced
this issue
Apr 7, 2024
* feat: Support `schema_extra` in `Parameter` and `Body` (#3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response). * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> --------- Co-authored-by: Jacob Coffee <jacob@z7x.org>
provinzkraut
pushed a commit
to robswc/litestar
that referenced
this issue
Apr 7, 2024
…3204) * feat: Support `schema_extra` in `Parameter` and `Body` (litestar-org#3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response). * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> --------- Co-authored-by: Jacob Coffee <jacob@z7x.org>
provinzkraut
pushed a commit
to robswc/litestar
that referenced
this issue
Apr 7, 2024
…3204) * feat: Support `schema_extra` in `Parameter` and `Body` (litestar-org#3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response). * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> --------- Co-authored-by: Jacob Coffee <jacob@z7x.org>
provinzkraut
pushed a commit
to robswc/litestar
that referenced
this issue
Apr 7, 2024
…3204) * feat: Support `schema_extra` in `Parameter` and `Body` (litestar-org#3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response). * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> --------- Co-authored-by: Jacob Coffee <jacob@z7x.org>
peterschutt
pushed a commit
that referenced
this issue
Apr 9, 2024
* feat: Support `schema_extra` in `Parameter` and `Body` (#3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response). * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> * Update litestar/params.py Co-authored-by: Jacob Coffee <jacob@z7x.org> --------- Co-authored-by: Jacob Coffee <jacob@z7x.org>
|
It did not add the same for |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
Pydantic provides
Field(json_schema_extra=...)which allows to do something like:This would generate:
It doesn't actually add/do any validation, it merely impacts the generated JSON schema.
Similar mechanism is needed for
Parameter, to inject discriminators (e.g.anyOf,not) into the OpenAPI spec (although the validation is decoupled from the schema declaration).The builtin generation uses
oneOffor union types (IIRC Pydantic usesanyOffor those). But I don't think it's possible to declare something like above.Workarounds at this point would be:
Operationclass (did not try but I assume it could work)OpenAPIPlugin?)Both are quite ugly hacks, while something like this should be supported out-of-the-box.
Basic Example
No response
Drawbacks and Impact
No response
Unresolved questions
No response
Note
While we are open for sponsoring on GitHub Sponsors and
OpenCollective, we also utilize Polar.sh to engage in pledge-based sponsorship.
Check out all issues funded or available for funding on our Polar.sh dashboard
The text was updated successfully, but these errors were encountered: