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

[IndexedDB] .value of no-duplicate cursors

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 30 Jun 2010 19:07:57 -0700
Message-ID: <AANLkTimCELErLDVxPE6Fnjsscg5uKV2KNf1ymcflNkkD@mail.gmail.com>
To: Webapps WG <public-webapps@w3.org>
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. However if
we do say that .value should represent a particular row, then I think
we should define which row is returned.

/ Jonas
Received on Thursday, 1 July 2010 02:08:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:39 GMT