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

Sorry, I always have problem with talking clearly.

Your experiment on this kind of problem is very interesting. I would like
to see what are optimal number of requests in a given transaction. These
two concepts (cursor walk and multi-request) can be employed together.

In my library implementation (ydn-db), multi-request is so commonly useful
that I had a pattern:

    var b = db.branch('multi', false); // multiple request parallel
transaction thread
    b.get('store1', key1);
    b.get('store1', key2); // parallel request
    b.get('store2', key1); // parallel transaction
    b.values('store2', keyrange1); // parallel request on second tx

On the other hand, we do not want large batch request, because it will
consume large memory. Conservation of memory is more important than CPU for
mobile.

I am excited batch query are planning in v2

    index.getAll(key_range, limit)
    objectStore.getAll(key_range, limit)

A lot of optimization could be done with that api.

Regarding array key or key_range query, i think it is NOT very useful.

    index.getAll(array_of_key_or_key_range, limit)

because we don't know result and respective query key.

Regarding prefix query, it is not very useful. It is trivial to create a
key range of desire prefix. Additionally we will also need start marker
key (as in aws s3 api), reverse order and limit. This method will destroy
current graceful api.





On Mon, May 20, 2013 at 9:37 PM, 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.
>
> > 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.
>
> > 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.
>
> > 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
>
>