search

strapi / rfcs

RFCs for Strapi future changes
70 stars 33 forks source link

Select fields by omission #46

Closed WalkingPizza closed 2 years ago

WalkingPizza commented 2 years ago

You can find the proposal here.

derrickmehaffy commented 2 years ago

Really love this idea but it would diverge our abstraction between the entityService and db query layer.

If it's possible to do with native Knex select (which is what we are abstracting) then we should go that way but I like the idea to use lodash in the abstraction and still just convert it to a select.

:+1:

alexandrebodin commented 2 years ago

Thanks for opening this RFC @WalkingPizza.

The main concern with omits in APIs is that the returned data is not predictable and can create problems with caching/respoonse size and such.

When you omit something but the API evolves you will start receiving new data that you might not want which could add a lot of overhead to your queries or break caching. This is why the preferred approach is only to select what you need and not the other way around.

I don't think this will make it to the core features but something I would like is to offer some extensibility to our query "language" for user specific usecases that wouldn't be in the core

WalkingPizza commented 2 years ago

Thanks for opening this RFC @WalkingPizza.

The main concern with omits in APIs is that the returned data is not predictable and can create problems with caching/respoonse size and such.

When you omit something but the API evolves you will start receiving new data that you might not want which could add a lot of overhead to your queries or break caching. This is why the preferred approach is only to select what you need and not the other way around.

I don't think this will make it to the core features but something I would like is to offer some extensibility to our query "language" for user specific usecases that wouldn't be in the core

I am sure this feature would have helped query-writers including myself quite a bit, but the points you bring up make total sense, so I guess we'll survive without this.

Looking forward to a more extensible query language in the future!