- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 11 Feb 2011 01:45:12 -0800
- 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 UTC