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

feat: pass examples given in the FieldDefinition to the OpenAPIMediaType #3222

Draft
wants to merge 25 commits into
base: v3.0
Choose a base branch
from

Conversation

robswc
Copy link

@robswc robswc commented Mar 17, 2024

New PR, based off of: #3128

Description

  • Passes examples given within the FieldDefinition to the OpenAPIMediaType
@post(media_type=MediaType.TEXT)
def create_person(
    self, data: Annotated[DataclassPerson, Body(examples=[Example(summary="this is an example", value={"key": "value"})])], secret_header: str = Parameter(header="secret")
) -> DataclassPerson:
    return data

image

Fixes

Fixes #3076

@robswc robswc requested review from a team as code owners March 17, 2024 21:38
@robswc robswc marked this pull request as draft March 17, 2024 21:39
Copy link

codecov bot commented Mar 17, 2024

Codecov Report

Attention: Patch coverage is 70.58824% with 5 lines in your changes are missing coverage. Please review.

Project coverage is 98.23%. Comparing base (43e3041) to head (58108c0).

Files Patch % Lines
litestar/_openapi/schema_generation/schema.py 60.00% 2 Missing and 2 partials ⚠️
litestar/_openapi/request_body.py 85.71% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             v3.0    #3222      +/-   ##
==========================================
- Coverage   98.26%   98.23%   -0.04%     
==========================================
  Files         322      322              
  Lines       14733    14749      +16     
  Branches     2343     2352       +9     
==========================================
+ Hits        14477    14488      +11     
- Misses        117      119       +2     
- Partials      139      142       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@robswc
Copy link
Author

robswc commented Mar 17, 2024

Original review/suggestions:

#3128 (review)

@robswc
Copy link
Author

robswc commented Mar 17, 2024

@provinzkraut Hey! It has been awhile since I have worked on this feature. I had to create a new PR as I had some issues with the way I originally forked the project.

That said, I have made the changes you mentioned in your review here:

#3128 (review)

Tests and pre-commits seem to pass but I get mypy and pyright errors. I remember now that is why I added some of the things I did. Was looking for further feedback on how to proceed. Thanks!

@peterschutt
Copy link
Contributor

peterschutt commented Mar 23, 2024

Do you still get errors from type checking if you run the checks on python 3.8? Nvm - I see they are occurring in CI.

@robswc
Copy link
Author

robswc commented Apr 2, 2024

Hey! If anyone could check this out it would be much appreciated!

I get this failure in the type-checking CI:

error: Argument "examples" to "OpenAPIMediaType" has incompatible type "Optional[Mapping[str, Example]]"; expected "Optional[Dict[str, Union[Example, Reference]]]

https://github.com/litestar-org/litestar/actions/runs/8480802759/job/23237155365?pr=3222#step:6:18

I had previously changed the types:

 -  examples: dict[str, Example | Reference] | None = None
 +  examples: dict[str, Example | Reference] | Mapping[str, Example] | None = None

provinzkraut pointed out the following, which I agree with:

While I think this is a good change, it's unfortunately breaking; If someone is using this attribute and referring to dict-only methods on it, passing a different type of mapping here would break their code and also their type checking.

However, I'm not sure how to proceed.

Thanks!

@provinzkraut
Copy link
Member

However, I'm not sure how to proceed.

There are 2 options:

  1. Figure out how to accomplish this without breaking changes
  2. Point the PR to the v3.0 branch

(also, if you @-tag me, it's easier to see something needs my attention 🙂)

@robswc
Copy link
Author

robswc commented Apr 2, 2024

However, I'm not sure how to proceed.

There are 2 options:

  1. Figure out how to accomplish this without breaking changes
  2. Point the PR to the v3.0 branch

(also, if you @-tag me, it's easier to see something needs my attention 🙂)

Awesome! I try to avoid @-ing unless its urgent but I'll keep it in mind! Thanks for your suggestions, I will try pointing to v3.0

@robswc robswc changed the base branch from develop to v3.0 April 2, 2024 16:31
Copy link

github-actions bot commented Apr 2, 2024

Documentation preview will be available shortly at https://litestar-org.github.io/litestar-docs-preview/3222

@robswc
Copy link
Author

robswc commented Apr 2, 2024

@provinzkraut - does this look ok 😅 ? I followed the suggestion of rebasing. Everything appears to be in order but I'm inexperienced with rebasing. It says 26 files have changed when, IIRC, I only changed ~3.

Thanks again for the feedback/back and forth!

tuukkamustonen and others added 8 commits April 7, 2024 19:02
…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]>
* feat: Added precedence of CLI parameters over envs

* Update docs/usage/cli.rst

Co-authored-by: Peter Schutt <[email protected]>

* Remove redundant LitestarEnv fields and fix tests

* Update docs/usage/cli.rst

* Update litestar/cli/commands/core.py

* Update docs/usage/cli.rst

* Update docs/usage/cli.rst

* Update litestar/cli/commands/core.py

---------

Co-authored-by: kedod <kedod>
Co-authored-by: Peter Schutt <[email protected]>
Co-authored-by: Jacob Coffee <[email protected]>
…pe, within request_body.py

(cherry picked from commit 821d3bc)
(cherry picked from commit 0eded49)
…pe, within request_body.py

(cherry picked from commit 821d3bc)
JacobCoffee and others added 7 commits April 7, 2024 19:03
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants