On Fri, Mar 4, 2011 at 11:33 AM, Ben Dilts <b...@lucidchart.com> wrote:
> Jeremy, > > Thanks for the reply! However, my indices are not typically unique, > contiguous numbers. For example, I have an index on an item's "saved" date, > as a MySQL-style date/time string. These dates are not necessarily unique, > and are certainly not contiguous. So if a user is currently viewing the > first 20 items in this object store, and would like to jump to page 5 (items > 81-100), how would I go about that? I don't know what key value is in the > 81st position in the index. In fact, the key value in position 81 may also > occupy positions 80 and 82--if I skip to that key value, I may end up in a > slightly wrong place. > If you're jumping beyond what you've already looked at, then yeah...the current API is probably not sufficient. I wouldn't mind adding an option to openCursor to start the cursor some number of items forward of the first element in the key range. I also wouldn't mind adding some sort of "jumpForward" method to IDBCursor. J > On Fri, Mar 4, 2011 at 11:33 AM, Jeremy Orlow <jor...@chromium.org> wrote: > >> On Tue, Mar 1, 2011 at 11:02 PM, Ben Dilts <b...@lucidchart.com> wrote: >> >>> Why is there no mechanism for paging results, a la SQL's "limit"? If I >>> want entries in positions 140-159 from an index, I have to call continue() >>> on a cursor 139 times, which in turn unserializes 139 objects from my store >>> that I don't care about, which in FF4 is making a lookup in IndexedDB >>> sometimes take many seconds for even a few records. It makes no sense--am I >>> just missing something in the spec? >> >> >> Just use cursor.continue() with a key parameter to skip the cursor ahead >> to where you care about. >> >> J >> > >