litestar-org / litestar

Production-ready, Light, Flexible and Extensible ASGI API framework | Effortlessly Build Performant APIs
https://litestar.dev/
MIT License
5.53k stars 377 forks source link

Bug: Different behavior for generating openapi schema names #3427

Open ryou90 opened 6 months ago

ryou90 commented 6 months ago

Description

Hi, when creating the Openapi schema there is a different behavior for generating the schema names. When I create a route with a dataclass, the Openapi schema is generated with the dataclass name. However, if I use a DTO wrapper, a completely different name is generated.

Is there a way to specify the name for a DTO class individually?

URL to code causing the issue

No response

MCVE

from litestar.dto import DataclassDTO

@dataclass
class App:
    id: int
    name: str
    description: str

@dataclass
class AppCreate:
    name: str
    description: str

class AppCreateDto(DataclassDTO[AppCreate]):
    pass

...

class AppController(Controller):
    """Handles the interactions within the App objects."""

    tags = ["Apps"]

# Variant 1 with dto:
    @post(
        path="/app",
        operation_id="create_app",
        name="apps:create",
        summary="Create App",
        dto=AppCreateDto,
    )
    async def create_app(
        self,
        data: DTOData[AppCreate]
    ) -> App:
      # Do something and return App
      ...

# Variant 2 without dto:
    @post(
        path="/app",
        operation_id="create_app",
        name="apps:create",
        summary="Create App",
    )
    async def create_app(
        self,
        data: AppCreate
    ) -> App:
      # Do something and return App
      ...

....

```json

with dto:

    "paths": {
        "/app_dto": {
            "post": {
                "tags": [
                    "Apps"
                ],
                "summary": "Create App",
                "description": "Create a new app.",
                "operationId": "create_app",
                "requestBody": {
                    "content": {
                        "application/json": {
                            "schema": {
                                "$ref": "#/components/schemas/CreateAppCreateRequstBody"
                            }
                        }
                    },
                    "required": true
                },

without dto:
    "paths": {
        "/app_dto": {
            "post": {
                "tags": [
                    "Apps"
                ],
                "summary": "Create App",
                "description": "Create a new app.",
                "operationId": "create_app",
                "requestBody": {
                    "content": {
                        "application/json": {
                            "schema": {
                                "$ref": "#/components/schemas/AppCreate"
                            }
                        }
                    },
                    "required": true
                },

Steps to reproduce

No response

Screenshots

No response

Logs

No response

Litestar Version

2.8.2

Platform


[!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

  • If you would like to see an issue prioritized, make a pledge towards it!
  • We receive the pledge once the issue is completed & verified
  • This, along with engagement in the community, helps us know which features are a priority to our users.

Fund with Polar

peterschutt commented 6 months ago

I've detailed my thoughts on the DTO naming and why it is like it is in this discord: https://discord.com/channels/919193495116337154/1227621024481411223/1228558632363364412 - you might like to read that.

ryou90 commented 6 months ago

Thx for the link. I understand why a defined naming scheme is used for DTOs. But on the other hand, the developer should be able to define his own unique name. For Pydantic models there is also the possibility (__schema_name__). The fact is that the given naming scheme is absolutely impractical when generating Openapi clients.