Open jaydenwindle opened 3 weeks ago
Hi, thanks for opening. I'm open to this addition, but have some ideas for how to tweak it:
totalCount
field on the Connection type itself (see https://graphql.org/learn/pagination/#end-of-list-counts-and-connections). In our case, that would look like this:
query {
friends(where: { id_lt: 100 }) {
items {
id
name
age
}
pageInfo {
endCursor
hasNextPage
}
totalCount # On the Page type, not the PageInfo type
}
}
totalCount
more often than needed, which can easily wreck performance. When rendering a paginated view, you likely only need to query the total count once up-front. Don't have an immediate solution - might be as simple as a warning callout in the docs.findMany
function signature type, and I have some naming ideas there. Will follow up with a few commits. We also need to update two docs pages accordingly:
Thanks for considering this!
We can definitely move totalCount
into the Connection type, that makes a lot more sense.
I agree that the performance considerations should be mentioned in the docs. It seems like there may be a way to use CTEs to include both queries in a single database call without too much performance overhead. Happy to investigate this if performance is a big concern.
@0xOlias I have refactored the totalCount
query logic to use CTEs instead of a second database call in order to mitigate the performance concerns. I've also moved the totalCount
field to the connection type, renamed the findMany
argument to withTotalCount
, and updated the documentation (with a warning about performance implications).
Let me know if there are any other changes you would like me to make!
This PR adds an additional field
totalCount
to the connection type for all plural queries. If thetotalCount
field is included in a query, an additional database call is made to fetch the total number of unique records matching the currently appliedwhere
filters. If thetotalCount
field is not queried, no additional database calls are made.