Performance impact of .fn.select
The docs say that it cannot be optimized, but doesn't elaborate on exactly what that means or the impact.
Does anyone have any more info if these should be avoided unless absolutely necessary?
For example I have a query like this:
If I remove the
I'm assuming the removal of the primary_image is to reduce nulls from being in the fields, but having parent as an object breaks checks if I do something like
So if I have
I could totally be doing something wrong here, but this is what I've found worked for me. Kinda wish there was a clean way of doing a format after the query like the useQuery>.select() used to be.
The functional variant API cannot be optimized by the query optimizer or use collection indexes. It is intended for use in rare cases where the standard API is not sufficient.
Does anyone have any more info if these should be avoided unless absolutely necessary?
For example I have a query like this:
If I remove the
.fn it will return the object like { ... parent: {} } when there is no parent join found, but if I add the .fn it will be like { ... primary_image: null, parent: null }. I'm assuming the removal of the primary_image is to reduce nulls from being in the fields, but having parent as an object breaks checks if I do something like
!!item.parent for example. I'd need to update them all to be !!item.parent?.id. So if I have
.fn here it makes the return data cleaner, but at what cost?I could totally be doing something wrong here, but this is what I've found worked for me. Kinda wish there was a clean way of doing a format after the query like the useQuery>.select() used to be.