Open clintonb opened 4 months ago
How would you see this happen in practice? There would need to be a specification of the mapping between the DTO and the entity type. For example, you would likely want your searchableColumns
to be those of the DTO, but how would we infer the matching entity column name to query in the database from that?
You could make a utility function in your library that does both DTO instantiation, and argument mapping for you. I think the @Paginate
decorator also processes "invalid" column names, and only later, inside of the paginate
function are invalid columns ignored. This means that you could adjust the query
that @Paginate
produces to map the columns from DTO to entity columns:
@Get()
myPaginate(@Paginate() dtoQuery: PaginateQuery) {
return paginate(transformDtoQuery(myDTO, dtoQuery), repo, config)
}
You can inspect the produced query
object, if it contains for example a filter for dtoCol
, you should map that to entityCol
.
Let me know whether I understood your question correctly. If not, please show what you mean with a couple of API request/query/response snippets and some example DTO and entities.
@Helveg that's a good question. There would need to be a mapping between DTO and entity fields. This would allow for exposing DTO fields for search, while querying the DB based on the mapped fields.
I need to think about this more. We have ultimately built this in a custom fashion following: https://pietrzakadrian.com/blog/how-to-create-pagination-in-nestjs-with-typeorm-swagger. This lacks a lot of the user-facing query options available in nestjs-paginate.
My entities and DTOs are separated to ensure that the API representation and DB representation can evolve independently. nestjs-paginate works well for querying, but assumes the entity and DTO are the same.
Is there any desire to support a second step after querying—DTO instantiation—to support separating these concerns?