- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 4 Feb 2011 23:50:19 -0800
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps@w3.org
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. 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 don't feel super strongly on this though. / Jonas
Received on Saturday, 5 February 2011 07:51:13 UTC