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. 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 yield. 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
