W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [Bug 11948] New: index.openCursor's cursor should have a way to access the index's "value" (in addition to the index's key and objectStore's value)

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 4 Feb 2011 23:50:19 -0800
Message-ID: <AANLkTimmHewp538Skby=S1va1fyim911yE_WjR6X11t2@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps@w3.org
On Fri, Feb 4, 2011 at 3:30 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> We haven't used the term primary key too much in the spec, but I think a lot
> might actually be more clear if we used it more.  And I think it'd also make
> a good name here.  So I'm OK with that being the name we choose.
> Here's another question: what do we set primaryKey to for cursors opened via
> index.openKeyCursor and objectStore.openCursor?  It seems as though setting
> them to null/undefined could be confusing.  One possibility is to have
> .value and .primaryKey be the same thing for the former and .key and
> .primaryKey be the same for the latter, but that too could be confusing.  (I
> think we have this problem no matter what we name it, but if there were some
> name that was more clear in these contexts, then that'd be a good reason to
> consider it instead.)
> J
>
> For objectStore.openCursor, if we went with primaryKey, then would we set
> both key and primaryKey to be the same thing?  Leaving it undefined/null
> seems odd.

I've been pondering the same questions but so far no answer seems
obviously best.

One way to think about it is that it's good if you can use the same
code to iterate over an index cursor as a objectStore cursor. For
example to display a list of results in a table. This would indicate
that for objectStore cursors .key and .primaryKey should have the same
value. This sort of makes sense too since it means that a objectStore
cursor is just a special case of an index cursor where the iterated
index just happens to be the primary index.

This would leave the index key-cursor. Here it would actually make
sense to me to let .key be the index key, .primaryKey be the key in
the objectStore, and .value be empty. This means that index cursors
and index key-cursors work the same, with just .value being empty for
the latter.

So in summary

objectStore.openCursor:
.key = entry key
.primaryKey = entry key
.value = entry value

index.openCursor:
.key = index key
.primaryKey = entry key
.value = entry value

index.openKeyCursor:
.key = index key
.primaryKey = entry key
.value = undefined


There are two bad things with this:
1. for an objectStore cursor .key and .primaryKey are the same. This
does seem unneccesary, but I doubt it'll be a source of bugs or
require people to write more code. I'm less worried about confusion
since both properties are in fact keys.

2. You can't use the same code to iterate over a key-cursor and a
"normal" cursor and display the result in a table. However I suspect
that in most cases key cursors will be used for different things, such
as joins, rather than reusing code that would normally use values.

I don't feel super strongly on this though.

/ Jonas
Received on Saturday, 5 February 2011 07:51:13 GMT

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