Re: [IndexedDB] request feedback on IDBKeyRange.inList([]) enhancement

On Mon, May 20, 2013 at 12:08 PM, Ben Kelly <bkelly@mozilla.com> wrote:

> On May 20, 2013, at 1:39 PM, Joshua Bell <jsbell@google.com> wrote:
> > On Mon, May 20, 2013 at 6:37 AM, Ben Kelly <bkelly@mozilla.com> wrote:
> > On May 19, 2013, at 9:25 PM, Kyaw Tun <kyawtun@yathit.com> wrote:
> > > IDBKeyRange.inList looks practically useful, but it can be achieve
> continue (continuePrimary) cursor iteration. Performance will be comparable
> except multiple round trip between js and database.
> >
> > I'm sorry, but I don't understand this bit.  How do you envision getting
> the cursor in the first place here without a way to form a query based on
> an arbitrary key list?  I'm sure I'm just missing an obvious part of the
> API here.
> >
> >
> > Here's an example I whipped up:
> >
> > https://gist.github.com/inexorabletash/5613707
>
> Thanks!  Yes, I totally missed you could pass the next desired key to
> continue().
>
> Unfortunately I don't think this approach would help much with the use
> case I am looking at.  The round trips are significant and add up on this
> mobile platform.  Also, it appears this would lose any parallelism from
> issuing multiple get() requests simultaneously.


Yep - which is what Kyaw mentioned above. ("Performance will be
comparable..."). Just pointing it out for completeness.



> > > Querying by parallel multiple get in a single transaction should also
> be fast as well.
> >
> > Yes, Jonas Sicking did recommend a possible optimization for the
> multiple get() within a transaction.  It would seem to me, however, that
> this will likely impose some cost on the general single get() case.  It
> would be nice if the client had the ability to be explicit about their use
> case vs using a heuristic to infer it.
> >
> > In any case, I plan to prototype this in the next week or two.
> >
> > Thanks for taking this on - we'll be watching your implementation
> experience closely. :)
> >
> > Some discussion here:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16595
> >
> > (That also links to a very raw document with other "IDB v2" thoughts c/o
> a very informal google/moz brainstorming session.)
> >
> > One approach that adds generally useful primitives to IDB is (1)
> something akin to a key range that is a list of keys (per above) and (2)
> batch cursors that deliver up to N values at a time. Either of those is
> quite useful independently.
>
> The batch cursors do look useful.  I had not run into that need yet since
> I am actually working with our prefixed getAll() implementation.
>
>
> > > Additionally IDBKeyRange.inList violate contiguous key range nature of
> IDBKeyRange. It is assumed in some use case, like checking a key in the key
> range or not. If this feature are to be implemented, it should not mess
> with IDBKeyRange, but directly handle by index batch request.
> >
> > Good point.  I suppose an IDBKeySet or IDBKeyList type could be added.
> >
> > I'm not entirely convinced that's necessary. I don't believe we expose
> "is in range" in the platform currently, so exposing a new type to script
> seems excessive. On the other hand, range is a pretty well defined concept
> in general so it would be a shame to break it.
>
> I don't have a preference one way or another.  I'm happy to implement a
> new type or not as long we can make non-consecutive key queries fast.
>
> Thanks again.  I'll post back when I have the multi-get optimization
> prototyped out.
>

Cool. Knowing what performance difference you see between multi-get and
just a bunch of gets in parallel (for time to delivery of the last value)
will be interesting. A multi-get of any sort should avoid a bunch of
messaging overhead and excursions into script to deliver individual values,
so it will almost certainly be faster, but I wonder how significantly the
duration from first-get to last-success will differ.


>
> Ben
>
> >
> >
> > > Ignoring deplicating keys is not a useful feature in query. In fact, I
> will like result be respective ordering of given key list.
> >
> > Well, I would prefer to respect ordering as well.  I just assumed that
> people would prefer not to impose that on all calls.  Perhaps the cases
> could be separated:
> >
> >   IDBKeyList.inList([])                 // unordered
> >   IDBKeyList.inOrderedList([])  // ordered
> >
> > I would be happy to include duplicate keys as well.
> >
> > Thanks again.
> >
> > Ben
> >
> >
> >
>
>