denoland
[KV Feedback]: Return pagination metadata in `list`
🔍
- [x] Did you search for existing issues?
Type of feedback
Bug report
Description
Currently, list allows to paginate over the key space using the prefix and/or start/end selectors.
But since it returns an async iterator, there’s no way of getting the metadata of the pagination.
For example:
- totalCount: number of keys in key space
- hasNextPage: if there are more keys after the last key in the selected range
- hasPreviousPage: if there are more keys before the first key in the selected range
This makes it impossible for a client to know if it can paginate further or not, and it needs to try and fail to figure it out.
Could there be a built-in way to expose pagination metadata?
Steps to reproduce (if applicable)
No response
Expected behavior (if applicable)
No response
Possible solution (if applicable)
No response
Additional context
No response
Pagination metadata (cursor) is included in the async iterator returned by kv.list(): https://deno.land/api?unstable=&s=Deno.KvListIterator
Thanks, the cursor can indeed be used to compute if there is a next page in the direction of pagination. If it's not undefined there is a next page, if it's undefined there isn't.
But it doesn't tell us if there is a previous page in the opposite direction of pagination. Also, it doesn't give the total count of items over which we paginate.
But it doesn't tell us if there is a previous page in the opposite direction of pagination.
You should know it before calling kv.list(), because the cursor parameter being defined is equivalent to there being a previous page.
Also, it doesn't give the total count of items over which we paginate.
It is computationally expensive to count the items on every call to kv.list(). If this information is needed, you can use an atomic counter to maintain the count.
True, thanks.
A note though. Our assumption above isn't quite right. The existence of a cursor after iterating over the entries doesn't actually tell us if there is a next page.
If the range happens to end exactly at the last element, then there will be a cursor even though there won't be more elements after that.
I'm working around this by listing one more element than what I want, and deleting the last element from the list if it exists. If it exists there is a last cursor, and if it doesn't the last cursor is an empty string.
A simple hasNextPage (and equivalently hasPreviousPage) would still be more convenient.
For each of the requested property, there are cumbersome workarounds scattered around the internet.
I think an implementation guide in the official docs is the very least for RDBMS users need, especially if KV is designed to be a primitive without these features planned.
