- From: ben turner <bent.mozilla@gmail.com>
- Date: Fri, 4 Mar 2011 13:38:50 -0800
- To: Olli@pettay.fi
- Cc: public-webapps@w3.org
Firefox does lazily deserialize cursor values, so the slowdown you're noticing is most likely due to us preserving the order of request callbacks by queuing every continue() call in line with the rest of the transaction. Jonas had proposed a faster, high performance cursor that did not respect this ordering, maybe that's all that you'd need. However, a few thoughts: 1. How do you know Page 5 even exists? We haven't exposed a count() function yet... 2. I think we should expose a count() function! 3. Maybe we should expose a getAt(long index, <enum> direction); function on indexes and objectStores? -Ben On Fri, Mar 4, 2011 at 12:11 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote: > On 03/02/2011 09:02 AM, Ben Dilts 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. > > Sounds like there is something to optimize in the implementation. > Have you filed a bug https://bugzilla.mozilla.org/enter_bug.cgi?product=Core > component DOM ? > If not, please do so and attach a *minimal* testcase. > > > Thanks, > > > -Olli > > > It >> >> makes no sense--am I just missing something in the spec? >> >> >> Ben Dilts > >
Received on Friday, 4 March 2011 21:39:43 UTC