On Jan 27, 2011, at 3:52 AM, Matt Goodall wrote: > On 27 January 2011 11:13, Stefan Lang > <[email protected]>wrote: > >> I couldn't find a single sentence about the offset member >> of a view response in either the reference on couchone.com >> 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: http://wiki.apache.org/couchdb/HTTP_view_API >> >> 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) > req.query.limit. 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? thanks, -natevw
