feat: Support schema_extra in Parameter and Body
#3204
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tuukkamustonen
force-pushed
the
schema-extra-for-parameters-and-body
branch
from
cac47f5 to
4eca4a5
Compare
tuukkamustonen
force-pushed
the
schema-extra-for-parameters-and-body
branch
from
4eca4a5 to
5fb5d31
Compare
|
Uh, |
tuukkamustonen
force-pushed
the
schema-extra-for-parameters-and-body
branch
11 times, most recently
from
712557e to
010d422
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #3204 +/- ##
===========================================
+ Coverage 98.23% 98.25% +0.01%
===========================================
Files 322 322
Lines 14658 14665 +7
Branches 2330 2333 +3
===========================================
+ Hits 14400 14409 +9
+ Misses 117 116 -1
+ Partials 141 140 -1 ☔ View full report in Codecov by Sentry. |
tuukkamustonen
force-pushed
the
schema-extra-for-parameters-and-body
branch
from
010d422 to
58ff90f
Compare
tuukkamustonen
requested review from
JacobCoffee and
provinzkraut
as code owners
provinzkraut
force-pushed
the
schema-extra-for-parameters-and-body
branch
from
58ff90f to
a48ad58
Compare
provinzkraut
force-pushed
the
develop
branch
2 times, most recently
from
353ebca to
525cd4c
Compare
provinzkraut
force-pushed
the
schema-extra-for-parameters-and-body
branch
from
a48ad58 to
f5fa87c
Compare
|
I think this needs a rebase :) |
tuukkamustonen
force-pushed
the
schema-extra-for-parameters-and-body
branch
from
f5fa87c to
a605a2a
Compare
JacobCoffee
approved these changes
Mar 17, 2024
tuukkamustonen
force-pushed
the
schema-extra-for-parameters-and-body
branch
2 times, most recently
from
0994335 to
991962d
Compare
|
@provinzkraut You seem to have a convention to force push to Should I rebase this or...? |
…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).
Co-authored-by: Jacob Coffee <[email protected]>
Co-authored-by: Jacob Coffee <[email protected]>
Co-authored-by: Jacob Coffee <[email protected]>
tuukkamustonen
force-pushed
the
schema-extra-for-parameters-and-body
branch
from
991962d to
9a1c879
Compare
|
Documentation preview will be available shortly at https://litestar-org.github.io/litestar-docs-preview/3204 |
JacobCoffee
added a commit
that referenced
this pull request
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 <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> --------- Co-authored-by: Jacob Coffee <[email protected]>
provinzkraut
pushed a commit
that referenced
this pull request
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 <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> --------- Co-authored-by: Jacob Coffee <[email protected]>
provinzkraut
pushed a commit
that referenced
this pull request
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 <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> --------- Co-authored-by: Jacob Coffee <[email protected]>
provinzkraut
pushed a commit
that referenced
this pull request
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 <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> --------- Co-authored-by: Jacob Coffee <[email protected]>
robswc
pushed a commit
to robswc/litestar
that referenced
this pull request
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 <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> --------- Co-authored-by: Jacob Coffee <[email protected]>
JacobCoffee
added a commit
that referenced
this pull request
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 <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> --------- Co-authored-by: Jacob Coffee <[email protected]>
JacobCoffee
added a commit
that referenced
this pull request
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 <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> --------- Co-authored-by: Jacob Coffee <[email protected]>
provinzkraut
pushed a commit
that referenced
this pull request
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 <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> --------- Co-authored-by: Jacob Coffee <[email protected]>
provinzkraut
pushed a commit
to robswc/litestar
that referenced
this pull request
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 <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> --------- Co-authored-by: Jacob Coffee <[email protected]>
provinzkraut
pushed a commit
to robswc/litestar
that referenced
this pull request
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 <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> --------- Co-authored-by: Jacob Coffee <[email protected]>
provinzkraut
pushed a commit
to robswc/litestar
that referenced
this pull request
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 <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> --------- Co-authored-by: Jacob Coffee <[email protected]>
peterschutt
pushed a commit
that referenced
this pull request
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 <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> --------- Co-authored-by: Jacob Coffee <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
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 thekeyword parameter name in
Schema. The values are used to override items inthe generated
Schemaobject, so they must be in correct types (ie. not indictionary/json format).
The values are added at main level, without recursive merging (because we're
adjusting
Schemaobject and not a dictionary). Recursive merge would be muchmore work.
Chose not to implement the same for
ResponseSpecbecause response models aregenerated as schema components, while
ResponseSpeccan be locally different.Handling the logic of creating new components when
schema_extrais passed inResponseSpecwould be extra effort, and isn't probably as important as beingable to adjust the inbound parameters, which are actually validated (and for
which the documentation is even more important, than for the response).
Closes
#3022