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

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