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

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