- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 9 Feb 2011 16:00:50 -0800
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps@w3.org
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. / Jonas
Received on Thursday, 10 February 2011 00:01:43 UTC