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 11:50 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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.
>

As long as we're breaking backwards compatibility in the name of clarity, we
might as well change key to indexKey and keep it null undefined for
objectStore.openCursor I think.  This would eliminate the confusion.

If we do break compat, is it possible for FF4 to include these changes?  If
not, then I would actually lean towards leaving .key and .value as is and
having .primaryKey duplicate info for index.openKeyCursor and
objectStore.openCursor.


> 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'm not super worried about this.  I think it it's more important to be
clear than make it easy to share code between the different types of
cursors.

On the other hand, it would be nice if there were some way for code to be
able to figure out what type of cursor they're working with.  Since values
can be undefined, they won't be able to just look at .key, .primaryKey, and
.value to figure it out though.  Maybe we need some attribute that says what
type of cursor it is?

J