couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Goodall <>
Subject Re: offset in view response
Date Thu, 27 Jan 2011 11:52:34 GMT
On 27 January 2011 11:13, Stefan Lang <>wrote:

> I couldn't find a single sentence about the offset member
> of a view response in either the reference on
> or the reference on the wiki.
> Only thing I could find was this:
> "Note: If you use group_level, total_rows and offset will be omitted
> from the results (this is done to avoid scanning the entire tree. "
> here:
> Does it make sense to display this offset to the user in pagination
> (like "you are viewing elements 41 to 60 from 500")?
> And is it future-proof or only informal meta data?

I would avoid offset altogether from the application's point of view.

Firstly, the offset is the position of the first row returned as it exists
in the *entire* view. For example, if you have 3 docs called a, b, and c,
and query with no startkey then the offset will be 0. If you query with
startkey="b" then the offset will be 1 even though you didn't send a skip

Similarly, the "total_rows" returned in the view results is for the entire
view too, not just the bit between your startkey/endkey bounds.

In any case, you really don't want to page using skip=? because it causes
couchdb to walk rows unnecessarily until it finds the first row to actually

A startkey allows couchdb to jump directly to the start point in the view
index. So, to implement paging you really want to use startkey and
startkey_docid (for when your view's keys are not unique) with a limit. Set
the limit to the page size + 1 but only display page size rows; the extra
row will give you the value to use for startkey and startkey_docid (if
needed) of the next page.

- Matt

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message