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

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.

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

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

Received on Monday, 20 May 2013 19:08:33 UTC