W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: Indexed Database API

From: ben turner <bent.mozilla@gmail.com>
Date: Fri, 4 Mar 2011 13:38:50 -0800
Message-ID: <AANLkTi=CoPXoc6sY_nZXdGH2VWhry3qd4mRWA4d+vfEc@mail.gmail.com>
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?


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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:30 UTC