incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Vander Wilt <>
Subject Re: offset in view response
Date Sat, 29 Jan 2011 22:32:41 GMT
On Jan 27, 2011, at 3:52 AM, Matt Goodall wrote:
> 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
> arg.
> Similarly, the "total_rows" returned in the view results is for the entire
> view too, not just the bit between your startkey/endkey bounds.

I think Stefan provided a good example of how this information can be useful without misuing
&skip=, and when I finally noticed those values were available to views (and lists) I
immediately thought of several situations where they'd be handy. For another example, a list
function can check and output a "next" link only when (head.total_rows - head.offset) >

The question is: is this info provided only because of some architectural peculiarity that
may go away, or is it safe to assume that the offset/total_rows report will remain a stable
part of CouchDB's official view API?

View raw message