On May 20, 2013, at 1:39 PM, Joshua Bell <jsb...@google.com> wrote: > On Mon, May 20, 2013 at 6:37 AM, Ben Kelly <bke...@mozilla.com> wrote: > On May 19, 2013, at 9:25 PM, Kyaw Tun <kyaw...@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 > > >
