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

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

You can always tell objectStore cursors apart by looking at the
.source property which we've discussed adding to cursors. One solution
for telling index-cursors from index-key-cursors is to make the latter
simply not have a .value property (rather than having one that returns
undefined).

It's not the most convenient way of telling the cursor types apart,
but I'm also not sure the use case is important to make terribly easy.

I'll have to look into how much of this, if any, we can do for FF4.

/ Jonas

Received on Monday, 7 February 2011 23:48:08 UTC