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

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.


> 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.  It seems like
there'd be some value in returning the first or last value, though since an
app might know that all entries in some particular object store with some
particular key will share some other property in common.  (Of course, in
this case, it'd probably be better for the application to normalize the data
into multiple objectStores, but given that joins will be a pain and doing so
might be overkill, it still seems like a use case worth supporting.
 Especially since it's little additional effort on our part.)  If it's
between first and last, I'd just as soon say that we return the first value
associated with each key.  ...assuming we don't just get rid of this feature
for v1.

J