- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Fri, 4 Mar 2011 12:03:54 -0800
- To: Ben Dilts <ben@lucidchart.com>
- Cc: public-webapps@w3.org
- Message-ID: <AANLkTimq-+QTKc4EGo2vRQJdeqhOMso3_XyT5QexQoko@mail.gmail.com>
On Fri, Mar 4, 2011 at 11:33 AM, Ben Dilts <ben@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 <jorlow@chromium.org> wrote: > >> On Tue, Mar 1, 2011 at 11:02 PM, Ben Dilts <ben@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 >> > >
Received on Friday, 4 March 2011 20:04:45 UTC