Open maxalbert opened 3 months ago
This isn't a bug, as DTOs can be defined on layers, and it would be quite restrictive to only allow routes beneath a layer that has a dto defined, to only return that DTO supported type. For example:
class MyController(Controller):
return_dto = SomeDTO[SomeType]
@get("/{id:int}")
def get_handler(self) -> SomeType: ...
@get("/")
def list_handler(self) -> list[SomeType]: ...
@delete("/{id:int}")
def delete_handler(self) -> None: ...
In that example, the delete handler not returning a model instance shouldn't force the user to have to define the dto individually on all of the other handlers.
I can perhaps see some utility to raising an error if a dto is defined directly on a handler as in your example, and that handler doesn't utilise it - but strictly speaking, having a dto available for a handler, but not required to be used is a design decision.
Description
Below is a minimal example that showcases the issue.
The context in which this came up for me is that I'm trying to port an existing app which uses FastAPI/SQLModel to Litestar. As illustrated in the SQLModel docs (for example here), I have several pydantic models for read/write/db operations - most of which I would like to ditch in favour of Litestar's DTOs. I accidentally defined my return DTOs using the wrong pydantic model and things weren't working as expected - it would simply ignore the DTO and return the full, unfiltered data.
Since I'm new to the concept of DTOs it took me a while to figure out what the cause of the issue was. For a new user like me it would be very helpful to have Litestar print a prominent warning (if not abort with an error).
URL to code causing the issue
No response
MCVE
Steps to reproduce
Screenshots
Logs
No response
Litestar Version
Platform