Enhancement: Provide option to set DTOs for nested fields about litestar HOT 7 OPEN

What about supplying config objects, instead of full-blown DTOs?

config = DTOConfig(
    exclude={
        "id",
    },
    field_dto={
        "address": user_address_config,
        "pets": user_pets_config,
    }
)
ReadUserDTO = SQLAlchemyDTO[Annotated[User, config]]

from litestar.

Here's some questions:

• what should happen if the rename_strategy for the nested model is different to the parent model config?
• what about max_nested_depth? If the parent config has max_nested_depth=1 and the nested model has max_nested_depth=1, should a nested field of the nested model be included? Or, should the parent nested depth win?
• partial, would you expect a non-partial parent model should be allowed to contain a partial inner model?

from litestar.

That... are all good questions :D so, using configs instead of full DTO makes sense to me - in the end, the root DTO already takes care of processing any nested models it's just about sharing configs for nested models in an easy way.

For the other things it should be one general approach that is consistent - in my opinion: Parent overules child. The parent structure is used for handling communication, so it owns the interface description and should have last say in renaming and nesting and so on.

I'm not sure if I understand the last question: With partial you mean excluding fields? If so, then I'd say that is the point of having nested configs, no? To have a cleaner way of excluding fields per model instead of digging through all nested models from the parent DTO.

from litestar.

For the other things it should be one general approach that is consistent - in my opinion: Parent overules child. The parent structure is used for handling communication, so it owns the interface description and should have last say in renaming and nesting and so on.

Yeah, so it would just read the exclude, include, and any explicit field renames from the nested config objects.

I'm not sure if I understand the last question: With partial you mean excluding fields? If so, then I'd say that is the point of having nested configs, no? To have a cleaner way of excluding fields per model instead of digging through all nested models from the parent DTO.

partial makes the set of all fields not required for a model, basically for PATCH route handling.

from litestar.

Ah okay, so yea then for partial I'd also say parent overrules child config.

from litestar.

So I think how this would work then, is inside DTOConfig.__post_init__(), we'd take any of the nested config objects and build the dotted path include/exclude/renames into the parent configs include/exclude/rename fields. E.g., if parent had exclude={"foo"}, and the nested was {"bar": DTOConfig(exclude={"baz"})}, then the parent exclude would end up as {"foo", "bar.baz"} after __post_init__() has executed.

from litestar.

I have an implementation here #2465 that addresses this. I've tried it in production as well. My main use case is having a SQLAlchemy model in a dataclass.

The only thing missing in that implementation is writing tests.

from litestar.