It's possible to do it that way, it just needs a way to navigate down the correct btree nodes and it's pretty cheap. But it ceases to be cheap with partitioned setups, like in BigCouch.
Also since the index can change between reads, using offset may produce values out of order, duplicate or skipped values in your UI. Startkey + docid generally produces better semantics. -Damien On Sep 12, 2010, at 8:21 PM, Randall Leeds wrote: > Any reason why we don't put a document count in the btree index to make skip > cheap? >> >> On Sep 12, 2010, at 9:39 AM, Mikeal Rogers wrote: >> >>> For pagination you can use the skip parameter instead of trying to change >>> the startkey for each pagination. >>> >>> http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options >>> >>> ?startkey="foo"&limit=10 >>> ?startkey="foo"&limit=10&skip=10 >>> ?startkey="foo"&limit=10&skip=20 >>> >> >> You can but you shouldn't. >> >> The right way to do it is to use startkey and limit, as documented here. >> >> http://guide.couchdb.org/draft/recipes.html#fast >> >>> >>> On Sun, Sep 12, 2010 at 12:06 AM, Henrik Skupin <[email protected]> > wrote: >>> >>>> Hi, >>>> >>>> For my current Couch application I'm using pagination to show only 50 >>>> results per page. To navigate back and forward the endkey vs. startkey >>>> parameters are used. While startkey in combination with limit is working >>>> fine, endkey doesn't return results for [offset(endkey)-limit, >>>> offset(endkey)] but for [0, limit]. This makes pagination impossible for > me >>>> and looks like to be a bug. An example you can find here: >>>> >>>> http://mozmill.hskupin.info/general/reports >>>> >>>> After opening the page click 'Next' twice and check the URL of the >>>> 'Previous' link before clicking on it. The endkey parameter will not be >>>> obeyed and a click on that link causes the first page to be opened. >>>> >>>> The code can be found at: http://github.com/whimboo/mozmill-dashboard >>>> >>>> Is the above problem a known broken behavior and worth filing a bug? >>>> >>>> Thanks, >>>> Henrik >>>> >>
