- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 1 Jul 2010 14:25:47 -0700
- To: ben turner <bent@mozilla.com>
- Cc: Jeremy Orlow <jorlow@chromium.org>, Webapps WG <public-webapps@w3.org>
Replying to get Ben's email to the list as his address seems to be stuck in moderation... On Thu, Jul 1, 2010 at 1:37 PM, ben turner <bent@mozilla.com> wrote: > 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 Thursday, 1 July 2010 21:26:44 UTC