-
DescriptionIt seems that Starlite will return the non-alias field names for pydantic models in a response, but will generate the OpenAPI documentation based on the field aliases. Take this code for example: from humps import camelize
from pydantic import BaseModel
from starlite import Starlite, get
class User(BaseModel):
user_id: str = "A1"
user_name: str = "Starlite User"
class Config:
alias_generator = camelize
allow_population_by_field_name = True
@get("/")
def get_user() -> User:
return User()
app = Starlite(route_handlers=[get_user]) The expected response of the get_user route is: {"userId":"A1","userName":"Starlite User"} Instead, Starlite returns: {"user_id":"A1","user_name":"Starlite User"} The OpenAPI docs correctly interpret the alias. "User": {
"properties": {
"userId": {
"type": "string",
"title": "Userid",
"default": "A1"
},
"userName": {
"type": "string",
"title": "Username",
"default": "Starlite User"
}
},
"type": "object",
"title": "User"
} URL to code causing the issueNo response MCVENo response Steps to reproduce1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error ScreenshotsNo response LogsNo response Starlite Version1.5.9 Platform
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Hi @tspanos, thanks for bringing this up. This is something we should probably make a bit more clear. We don't export by alias when using let me know if this helps! def _base_model_encoder(value: BaseModel) -> dict[str, Any]:
return value.dict(by_alias=True)
app = Starlite(
...
type_encoders={ BaseModel: _base_model_encoder},
) |
Beta Was this translation helpful? Give feedback.
Hi @tspanos, thanks for bringing this up. This is something we should probably make a bit more clear. We don't export by alias when using
pydantic
. If you'd like to override this behavior, it's really simple. Here is how I'm doing it in my current application.let me know if this helps!