- From: ben turner <bent@mozilla.com>
- Date: Thu, 1 Jul 2010 13:37:40 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Jeremy Orlow <jorlow@chromium.org>, Webapps WG <public-webapps@w3.org>
I think I would be happy just removing the _NO_DUPLICATE directions. As Jeremy noted it is quite easy to emulate and it would then be up to the webapp author whether she wanted the first or last duplicate value. -Ben On Wed, Jun 30, 2010 at 11:56 PM, Jonas Sicking <jonas@sicking.cc> wrote: > 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 Friday, 2 July 2010 09:12:45 UTC