- From: <bugzilla@jessica.w3.org>
- Date: Mon, 29 Apr 2013 13:48:07 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21836 --- Comment #3 from Kyaw Tun <kyawtun@yathit.com> --- Thank Jonas, for very clear explanation. Both use case B) and C) must be able to specify. Previously, I was not understand the specification correctly. I was talking from developer point of view. In fact, array keyPath with multiEntry does not make sense and the specification is correct. What I refer turn out to be composite index (array keyPath) of multiEntry index. Composite index, itself, is not multiEntry. Bug 10000 sounds nice, but its implication is ugly. Indexing specification is the most beautiful part of IndexedDB API. It could go father, following google database store interpretation. Could we specify such that 1. multiEntry effect writing index. 2. element of array keyPath is evaluated as index value first and then keyPath of record value (current specification). If element of array keyPath is the name of index, its value is respective index value. If the name of index does not exist, it is evaluated as usual. In this way both use case B) and C) can be specified intuitively. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 29 April 2013 13:48:08 UTC