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)

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 UTC