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 Wed, Feb 9, 2011 at 4:00 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Feb 7, 2011 at 3:55 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > 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.
>
> My thinking was that iterating over an objectStore and iterating over
> an index should essentially expose the same API. So iterating over the
> objectStore is basically just iterating over the index that happens to
> be the primary key.
>
> In this light, the following API makes a lot of sense:
>
> objectStore.openCursor:
> .key = entry key
> .primaryKey = entry key
> .value = entry value
>
> index.openCursor:
> .key = index key
> .primaryKey = entry key
> .value = entry value
>
> In other words, you access .key if you want to get the value of the
> property you are currently iterating using, and you access .primaryKey
> if you need to get a reference which uniquely identifies the entry
> (for example for use as unique identifier in a join, or for outputting
> links to entries).
>
> It seems like we agree that a index-key-cursor should have the same
> API as normal index-cursors, with just .value missing.


Makes sense.  Let's do that then.

J