- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 30 Jun 2010 23:56:20 -0700
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Webapps WG <public-webapps@w3.org>
On Wed, Jun 30, 2010 at 10:42 PM, Jeremy Orlow <jorlow@chromium.org> wrote: > On Thu, Jul 1, 2010 at 12:07 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> Hi All, >> >> This was one issue we ran into while implementing IndexedDB. In the >> code examples I'll use the mozilla proposed asynchronous APIs, but the >> issue applies equally to the spec as it is now, as well as the >> synchronous APIs. >> >> Consider an objectStore containing the following objects: >> >> { id: 1, name: "foo", flags: ["hi", "low"] } >> { id: 2, name: "foo", flags: ["apple", "orange"] } >> { id: 3, name: "foo", flags: ["hello", "world"] } >> { id: 4, name: "bar", flags: ["fahrvergnügen"] } >> >> And an index keyed on the "name" property. What should the following code >> alert? >> >> results = []; >> db.objectStore("myObjectStore").index("nameIndex").openCursor(null, >> IDBCursor.NEXT_NO_DUPLICATE).onsuccess = function(e) { >> cursor = e.result; >> if (!cursor) { >> alert(results.length); >> alert(results); >> } >> results.push(cursor.value); >> cursor.continue(); >> }; >> >> It's clear that the first alert would display '2', as there are 2 >> distinct 'name' values in the objectStore. However it's not clear what >> the second alert would show. I.e. what would cursor.value be on each >> 'success' event firing? >> >> We could define that it is one of the rows matching the distinct >> value. In that case either "1,4", "2,4" or "3,4" would be valid values >> for the second alert. If we choose that solution then ideally we >> should define which one and make it consistent in all implementations. >> >> Alternatively we could say that .value is null for all *_NO_DUPLICATE >> cursors. >> >> The question equally applies if the above code used openObjectCursor >> rather than openCursor. However if we define that .value is null for >> *_NO_DUPLICATE cursors, then openObjectCursor with *_NO_DUPLICATE >> doesn't make much sense in that it returns the same thing as >> openCursor with *_NO_DUPLICATE. >> >> I don't personally don't care much which solution we use. I'm unclear >> on what the exact use cases are for *_NO_DUPLICATE cursors. > > This is a very good point. What are the use cases? After all, you can > easily emulate such a cursor yourself. Unless there are some compelling use > cases, I'd be happy to just get rid of it. Same here. Though I suspect there are use cases as SQL has a similar feature (SELECT DISTINCT). >> However if >> we do say that .value should represent a particular row, then I think >> we should define which row is returned. > > Agreed that it should be deterministic. I'm fine with null, the first > value, or the last value. If we do null, then I think calling > openObjectCursor with *_NO_DUPLICATE should be an error. Agreed. We just have to define what "first" and/or "last" means. Two alternatives are insertion order or order in objectStore. I prefer the latter as to avoid introducing insertion order as a concept. Hmm.. come to think of it, we likely have to define an order anyway. So that it is deterministic what the order of the example index is defined when iterated with a "normal" cursor. I filed a bug on getting that defiend: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10058 / Jonas
Received on Thursday, 1 July 2010 07:04:49 UTC