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 Wed, Feb 9, 2011 at 4:47 PM, Jeremy Orlow wrote: > On Wed, Feb 9, 2011 at 4:00 PM, Jonas Sicking wrote: >> >> On Mon, Feb 7, 2011 at 3:55 PM, Jeremy Orlow wrote: >> > On Mon, Feb 7, 2011 at 3:47 PM, Jonas Sicking wrote: >> >> >> >> On Sat, Feb 5, 2011 at 11:02 AM, Jeremy Orlow >> >> wrote: >> >> > On Fri, Feb 4, 2011 at 11:50 PM, Jonas Sicking >> >> > wrote: >> >> >> >> >> >> On Fri, Feb 4, 2011 at 3:30 PM, Jeremy Orlow >> >> >> 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
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 Wed, Feb 9, 2011 at 4:00 PM, Jonas Sicking wrote: > On Mon, Feb 7, 2011 at 3:55 PM, Jeremy Orlow wrote: > > On Mon, Feb 7, 2011 at 3:47 PM, Jonas Sicking wrote: > >> > >> On Sat, Feb 5, 2011 at 11:02 AM, Jeremy Orlow > wrote: > >> > On Fri, Feb 4, 2011 at 11:50 PM, Jonas Sicking > wrote: > >> >> > >> >> On Fri, Feb 4, 2011 at 3:30 PM, Jeremy Orlow > >> >> 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 th
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 Mon, Feb 7, 2011 at 3:55 PM, Jeremy Orlow wrote: > On Mon, Feb 7, 2011 at 3:47 PM, Jonas Sicking wrote: >> >> On Sat, Feb 5, 2011 at 11:02 AM, Jeremy Orlow wrote: >> > On Fri, Feb 4, 2011 at 11:50 PM, Jonas Sicking wrote: >> >> >> >> On Fri, Feb 4, 2011 at 3:30 PM, Jeremy Orlow >> >> 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
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 Mon, Feb 7, 2011 at 3:47 PM, Jonas Sicking wrote: > On Sat, Feb 5, 2011 at 11:02 AM, Jeremy Orlow wrote: > > On Fri, Feb 4, 2011 at 11:50 PM, Jonas Sicking wrote: > >> > >> On Fri, Feb 4, 2011 at 3:30 PM, Jeremy Orlow > 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. Here's another proposal (which is maybe what you meant?): objectStore.openCursor: .key = entry key .value = entry value index.openCursor: .indexKey = index key .key = entry key .value = entry value index.openKeyCursor: .indexKey = index key .key = entry key Note that I'm thinking we should probably sub-class IDBCursor for each type so that attributes don't show up if we're not going to populate them. Which we maybe should do for IDBRequest as well? J
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 wrote: > On Fri, Feb 4, 2011 at 11:50 PM, Jonas Sicking wrote: >> >> On Fri, Feb 4, 2011 at 3:30 PM, Jeremy Orlow 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
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 Fri, Feb 4, 2011 at 11:50 PM, Jonas Sicking wrote: > On Fri, Feb 4, 2011 at 3:30 PM, Jeremy Orlow 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. > 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? J
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 Fri, Feb 4, 2011 at 3:30 PM, Jeremy Orlow 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
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)
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. On Fri, Feb 4, 2011 at 1:36 PM, Jonas Sicking wrote: > On Fri, Feb 4, 2011 at 11:14 AM, Shawn Wilsher > wrote: > > On 2/1/2011 11:00 AM, bugzi...@jessica.w3.org wrote: > >> > >> As discussed in the mailing list thread from bug 11257, we should add > some > >> way > >> for index.openCursor cursors to access the primary key for the > >> objectStore. > >> .indexValue, .objectStoreKey, or .primaryKey might be good names to use > >> for it. > > > > .objectStoreKey seems to be the most clear way to express this to me. > > Oh, I missed that the original bug included a few suggestions. Given > that both me and Jeremy independently thought of "indexValue" and > "primaryKey" I think that's a decent sign that they are intuitive > names. I happen to like "primaryKey" the most as it's really a key > rather than a value that we've got here. > > For some reason objectStoreKey makes me think that it's connected to > the objectStore rather than the entry in it. > > / Jonas > >
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 Fri, Feb 4, 2011 at 11:14 AM, Shawn Wilsher wrote: > On 2/1/2011 11:00 AM, bugzi...@jessica.w3.org wrote: >> >> As discussed in the mailing list thread from bug 11257, we should add some >> way >> for index.openCursor cursors to access the primary key for the >> objectStore. >> .indexValue, .objectStoreKey, or .primaryKey might be good names to use >> for it. > > .objectStoreKey seems to be the most clear way to express this to me. Oh, I missed that the original bug included a few suggestions. Given that both me and Jeremy independently thought of "indexValue" and "primaryKey" I think that's a decent sign that they are intuitive names. I happen to like "primaryKey" the most as it's really a key rather than a value that we've got here. For some reason objectStoreKey makes me think that it's connected to the objectStore rather than the entry in it. / Jonas
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 2/1/2011 11:00 AM, bugzi...@jessica.w3.org wrote: As discussed in the mailing list thread from bug 11257, we should add some way for index.openCursor cursors to access the primary key for the objectStore. .indexValue, .objectStoreKey, or .primaryKey might be good names to use for it. .objectStoreKey seems to be the most clear way to express this to me. Cheers, Shawn smime.p7s Description: S/MIME Cryptographic Signature
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 Tue, Feb 1, 2011 at 11:00 AM, wrote: > http://www.w3.org/Bugs/Public/show_bug.cgi?id=11948 > Summary: 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) I got poked regarding coming up with name suggestions. I don't really have any good ones, but here's a few: indexValue entryKey valueKey primaryKey Not in love with any of them so please feel free to suggest others. / Jonas
