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 Mon, Feb 7, 2011 at 3:47 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Sat, Feb 5, 2011 at 11:02 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > 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.
>
> Actually, I quite like the idea of having objectStore-cursors just be
> a special case of index-cursors. Which also allows us to keep the nice
> and short name "key" of being the key that you are iterating (be that
> a primary key or an index key).


Can you explain further?  I don't fully understand you.

Here's another proposal (which is maybe what you meant?):

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

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

index.openKeyCursor:
.indexKey = index key
.key = entry key

Note that I'm thinking we should probably sub-class IDBCursor for each type
so that attributes don't show up if we're not going to populate them.

Which we maybe should do for IDBRequest as well?

J