Proposition: signal the end of a paginated query

For now, a query gives a collection of rows, and the total number of rows. I’d like to discuss the inclusion of a new field that I’d find useful when using a limit. This would be either the index of the first row in the collection, or a boolean flag indicating whether there are still some rows after the retrieved ones.

Imagine the following case: you have a query that you access with pagination as described in this blog article. While you know the first time that you begin at index 0, for the second page you don’t know anymore the indexes you display. You could store a page number along, but this would be potentially wrong, as while you’re browsing the pages, new documents could be inserted in-between.

If the number of retrieved rows is equal to the limit of the query, you can’t tell if the page you display currently is the last page or not. Therefore, you need to make another query, which could yield no rows. This could be prevented if a query informs whether it’s the last query to make.

I don’t know the costs of executing a query with no results versus adding a new field to the response stream.

Hi @Bloutiouf,
Thanks for the feedback and your interest in helping us improve.

Could you give a JSON response sample for the ekstra attribute as you would like it implemented?
The sample would make it much easier for us to evaluate your suggestion.

Thanks
Martin

Sure, here is an example. I query a view with, let’s say, `startkey=5&startkey_docid=tk-1438639846933-8&skip=1&limit=10. The server sends the following JSON.

{
	total_rows: 120,
	rows: [
		{
			id: "tk-1438639846933-10",
			key: 5,
			value: null
		},
		{
			id: "tk-1438639846933-11",
			key: 8,
			value: null
		},
		...
		{
			id: "tk-1438639846933-116",
			key: 24,
			value: null
		}
	]
}

But I have no information about whether it would be useful to make a further query startkey=24&startkey_docid=tk-1438639846933-116&skip=1&limit=10.

The proposition would be to add either a start index

{
	total_rows: 120,
	start_index: 35,
	rows: [...]
}

or a flag indicating whether the end has been reached

{
	total_rows: 120,
	depleted: false,
	rows: [...]
}

I think the former is more powerful, as it adds more value. For instance, if somehow we keep a page index, say 2, with 10 rows per page, together with the startkey and startkey_docid that we send to the server, and the server gives a start_index: 22, then we can display to the user that two new rows have popped out in the previous pages, etc.