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, 11 Feb 2011 01:45:12 -0800
Message-ID: <AANLkTindQiBS88jWPaN6TO4jZZUmEzeZQM33gxPH28d1@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps@w3.org
On Wed, Feb 9, 2011 at 4:47 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> 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.

For what it's worth, I was able to get this into Firefox 4 just in
time. Should be in tomorrows nightly as well as beta 12.

/ Jonas
Received on Friday, 11 February 2011 09:46:19 GMT

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