pagination enhancements
Looking for a couple enhancements to paginated queries:
1) Count on the response. Its valuable to inform the user of the total number of records available to paginate through.
2) 'skip' arg shortcircuiting like
useQuery has.
Either of these on the roadmap?7 Replies
unfortunately (1) is difficult. for an ad-hoc query, you can't do much better than paginating through all documents. if you're looking through the whole table, you can use
db.query("table").count() (unstable api caveats) and we're considering how to implement fast aggregations that are kept up-to-date (you can keep track of this yourself but then you might get OCC conflicts -- see other threads mentioning aggregation).definitely need to count at least on an indexed subset of the table
for (2) we can probably implement 'skip', thanks for the feature request!
thanks lee. I'll hack around it for now.
For some context, I'm trying to manage consumption tracking in a paid product. Eg: you are on a basic plan with 250 seats, how many are currently consumed and should the ux allow inviting additional users...
my plan is to just add the consumed amount as a field and run a reconciliation patch when key events occur. But it seems a bit fragile and would prefer to run direct counts against the db.
agreed db support would be more convenient. i was considering writing up code for the pattern of keeping an async aggregation as a separate field. let us know if that would be useful.
Lee, we're running into the same issues (we've been in touch with Tom). A thought-out code example for the recommended pattern would certainly help. But having this aggregation out of the box (however it is implemented) and with no risk of OCC conflicts would be ideal.
Btw, what are the "unstable api caveats" that you're referring to?
re
.count() it's not documented and doesn't have compatibility guarantees https://discord.com/channels/1019350475847499849/1019350478817079338/1164366097764581406