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

I'm person


On Fri, May 17, 2013 at 2:37 PM, Ben Kelly <bkelly@mozilla.com> wrote:

> Hello all,
>
> Recently I've been working on a mobile application that makes heavy use of
> IndexedDB.  In particular, there are times when this app must query a
> potentially large, non-consecutive list of keys.  Currently (to my
> knowledge) the IndexedDB API requires that this be done via separate get()
> calls.  Due to some performance issues I investigated enhancing the
> IndexedDB API to allow the list of keys to be queried in a single request.
>  The resulting changes seem to show significant performance improvement on
> the mozilla mobile platform.
>
> I would like to get your feedback and input on this API change.
>
> The enhancement essentially adds an inList() function to IDBKeyRange.
>  Similar to the other factory methods on IDBKeyRange, this returns an
> object which can be used to query a matching set of keys.  The inList()
> function takes an array of keys to match against.  In practice it would
> look like the following:
>
>   var keyRange = IDBKeyRange.inList(['key-1', 'key-2', 'key-3']);
>   var request = index.openCursor(keyRange);
>
> Duplicate keys in the list are ignored.  The order of the results would be
> controlled by the normal cursor ordering mechanisms.
>
> I've written a rough proof-of-concept for the mozilla platform here:
>
>   https://bugzilla.mozilla.org/show_bug.cgi?id=872741
>
> I realize there has been some discussion of this topic in the past.  In
> particular, Ben Turner referred me to:
>
>   https://www.w3.org/Bugs/Public/show_bug.cgi?id=16595
>
> https://docs.google.com/a/mozilla.com/document/d/1vvC5tFZCZ9T8Cwd2DteUvw5WlU4YJa2NajdkHn6fu-I/edit
>
> From these links it sounds like there has been a lack of interest, but no
> strong objection.  Since there appears to be some legitimate benefit from
> the API enhancement I thought I would send it out to the list for feedback.
>  I have to admit I'm new to the standardization process, though.  I
> apologize for the noise if this is essentially a non-starter.
>

I have mixed feelings on this:

What you're really talking about is an API that groups the get's and the
get callbacks into a single call / callback - i.e. a simplification of the
flow of control through the async APIs - the fact that it may or may not be
a performance optimization is really an implementation detail. Its the
implementation's job to figure out if there are multiple parallel get()'s
in a turn that can be optimized. I think this is really the job of a
polyfill or a library (like Kyaw's ydn-db), not an implementation.


When you get down to the control-flow issue, you're really looking a
Futures.every() (I know, roll your eyes now and get it over with!) and
layers that could be built on top of that:

Futures.every(objectStore.get(...), objectStore.get(...),
objectStore.get(...)).then(function(result1, result2, result3) {
  // now you have result1, result2, result3, etc.
})

But since we don't have futures in IDB yet, we have to decide if its worth
adding this specialized API to IDB, or letting users suffer while they wait
for futures.

If it is decided that this should go into IDB, I don't think IDBKeyRange
should be used for discontinuous/multiple ranges, (because it totally
invalidates lower/upper/etc) so if we had to do this I'd personally go with
IDBKeySet/etc. I think this is too tricky to add directly to get() because
it changes the semantics of the call (i.e. if you say get([1,2,3]) how do
you distinguish between the 3 keys 1, 2, and 3, and the *key* [1,2,3]

Alec


> Any feedback is greatly appreciated.  Thank you!
>
> Ben Kelly
>
>