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

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