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

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 30 Jun 2010 23:56:20 -0700
Message-ID: <AANLkTillCdBijiXiyXztacSdsk7jqhRNi0be_yuu1VxP@mail.gmail.com>
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

>> 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:


/ Jonas
Received on Thursday, 1 July 2010 07:04:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:09 UTC