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

On Mon, May 20, 2013 at 6:37 AM, Ben Kelly <bkelly@mozilla.com> wrote:

> Thanks for the feedback!
>
> 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



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


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


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