Re: Indexed Database API

On Fri, Mar 4, 2011 at 1:38 PM, ben turner <bent.mozilla@gmail.com> wrote:

> 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?
>

A count function might make sense.

But in this case, you could just jump forward to page 5 and see if you get
an error or not.

I'd lean towards just adding jumping forward to cursors for now though.  If
getting a single item at some position is popular, then we can always add
it.

Let's avoid adding prioritization of cursor.continue calls unless we have
absolutely no other choice.

J

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
> >
> >
>
>