Thanks for the feedback! On May 19, 2013, at 9:25 PM, Kyaw Tun <[email protected]> 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
