W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [IndexedDB] .value of no-duplicate cursors

From: ben turner <bent@mozilla.com>
Date: Thu, 1 Jul 2010 08:21:25 -0700
Message-ID: <AANLkTinUx01ANxztbf4th7oXFC6QZ-oziMkb2v7LChJS@mail.gmail.com>
To: 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


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

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 14:36:44 UTC