Re: [indexeddb] Do we need to support keyPaths with an empty string?

[Jonas Sicking]

On Tue, Jan 24, 2012 at 12:07 PM, Israel Hilerio isra...@microsoft.com wrote:
 On Tuesday, January 24, 2012 2:46 AM Jonas Sicking wrote:
 On Fri, Jan 20, 2012 at 3:38 PM, Israel Hilerio isra...@microsoft.com
 wrote:
  On Friday, January 20, 2012 2:31 PM, Jonas Sicking wrote:
  On Fri, Jan 20, 2012 at 12:23 PM, ben turner bent.mozi...@gmail.com
 wrote:
   Mozilla is fine with removing the special |keyPath:| behavior.
   Please note that this will also mean that step 1 of the algorithm
   here
  
  
   http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-step
   s-f or-extracting-a-key-from-a-value-using-a-key-path
  
   will need to change.
  
   We do want to continue to allow set behavior without specifying the
   key twice, though, so we would propose adding an additional option
   to createObjectStore to accomplish this:
  
    // Old way:
    var set = db.createObjectStore(mySet, { keyPath: });
    set.put(keyValue);
  
    // New way:
    var set = db.createObjectStore(mySet, { isSet: true });
    set.put(keyValue);
  
   (We are not in love with isSet, better names are highly
   encouraged!)
  
   What do you all think? This would allow us to continue to support
   nice set behavior without making the empty string magic.
 
  I actually think that the current behavior that we have is pretty
  consistent. Any time you give the keyPath property a string we create
  an objectStore with a keyPath. And any time you have an objectStore
  with a keyPath you are not allowed to pass an explicit key since the
  key is gotten from the keyPath. There's no special handling of empty
 strings happening.
 
  But I do agree that it can be somewhat confusing to tell
  /null/undefined apart since they are all falsy. In particular, an
  expression like
 
  if (myObjectStore.keyPath) {
    ...
  }
 
  doesn't work to test if an objectStore has a keyPath or not. You
  instead need to check
 
  if (myObjectStore.keyPath != null) {
    ...
  }
 
  or
 
  if (typeof myObjectStore.keyPath == string) {
    ...
  }
 
  Hence the isSet suggestion.
 
  Though I also realized after talking to Ben that empty keyPaths show
  up in indexes too. Consider creating a objectStore which maps peoples
  names to email addresses. Then you can create an index when does the
  opposite mapping, or which ensures that email addresses are unique:
 
  var store = db.createObjectStore(people); var index =
  store.createIndex(reverse, , { unique: true });
  store.add(john@email.com, John Doe);
  store.add(m...@smith.org, Mike Smith);
 
  store.get(John Doe).onsuccess = function(e) {
    alert(John's email is  + e.target.result); }
 index.getKey(m...@smith.org).onsuccess = function(e) {
    alert(m...@smith.org is owned by  + e.target.result); }
 
  Are people proposing we remove empty keyPaths here too?
 
  / Jonas
 
  Yes, I'm proposing removing empty string KeyPaths all together to avoid
 confusion.
  I would like to know how often you expect developers to follow this
  pattern instead of using objects.  Our believe is that objects will be
  the main value stored in object stores instead of single values.
 
  Supporting keyPath with empty strings brings up all kinds of side effects.
 For example:
 
  var store = db.createObjectStore(people); var index =
  store.createIndex(reverse, , { unique: true });
  store.add({email: john@email.com}, John Doe);
  store.add({email: m...@smith.org},Mike Smith);
 
  What should happen in this case, do we throw an exception?

 This doesn't seem any different from

 var store = db.createObjectStore(people); var index =
 store.createIndex(reverse, x, { unique: true }); store.add({ x: {email:
 john@email.com} }, John Doe); store.add({ x: {email:
 m...@smith.org} },Mike Smith);

 IIRC we decided a while ago that indexes do not add constraints. I.e.
 that if the keyPath for an index doesn't yield a valid key, then the index
 simply doesn't get an entry pointing to newly stored value.

 So I don't really see that empty keyPaths bring up any special cases.
 The only special case we have in Firefox for empty keyPaths (apart from the
 keyPath evaluation code itself) is the code that throws an exception if you 
 try
 to create an objectStore with an empty keyPath and a key generator.

  Having some type of flag seems more promising for object stores.
  However, we still need to figure out how to deal with Indexes on sets, do
 we pass another flag to support the indexes on sets?  If we do that, then
 what do we do with the keyPath parameter to an index.
  It seems we're overloading the functionality of these methods to support
 different patterns.

 Indeed, supporting the same use cases but using something other than
 empty key paths gets pretty messy for indexes. If we want to keep supporting
 these use cases (which I personally do), then I think using empty key paths 
 is
 the cleanest solution.

 Really the only downside that I see is the somewhat non-intuitive
 objectStore.keyPath != null check. But 

RE: [indexeddb] Do we need to support keyPaths with an empty string?

[Israel Hilerio]

On Wednesday, January 25, 2012 1:47 AM, Jonas Sicking wrote:
 On Tue, Jan 24, 2012 at 12:07 PM, Israel Hilerio 
 isra...@microsoft.com
 wrote:
  On Tuesday, January 24, 2012 2:46 AM Jonas Sicking wrote:
  On Fri, Jan 20, 2012 at 3:38 PM, Israel Hilerio 
  isra...@microsoft.com
  wrote:
   On Friday, January 20, 2012 2:31 PM, Jonas Sicking wrote:
   On Fri, Jan 20, 2012 at 12:23 PM, ben turner 
   bent.mozi...@gmail.com
  wrote:
Mozilla is fine with removing the special |keyPath:| behavior.
Please note that this will also mean that step 1 of the 
algorithm here
   
   
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn
-s tep s-f or-extracting-a-key-from-a-value-using-a-key-path
   
will need to change.
   
We do want to continue to allow set behavior without 
specifying the key twice, though, so we would propose adding 
an additional option to createObjectStore to accomplish this:
   
 // Old way:
 var set = db.createObjectStore(mySet, { keyPath: });
 set.put(keyValue);
   
 // New way:
 var set = db.createObjectStore(mySet, { isSet: true });
 set.put(keyValue);
   
(We are not in love with isSet, better names are highly
encouraged!)
   
What do you all think? This would allow us to continue to 
support nice set behavior without making the empty string magic.
  
   I actually think that the current behavior that we have is 
   pretty consistent. Any time you give the keyPath property a 
   string we create an objectStore with a keyPath. And any time you 
   have an objectStore with a keyPath you are not allowed to pass 
   an explicit key since the key is gotten from the keyPath.
   There's no special handling of empty
  strings happening.
  
   But I do agree that it can be somewhat confusing to tell 
   /null/undefined apart since they are all falsy. In particular, 
   an expression like
  
   if (myObjectStore.keyPath) {
     ...
   }
  
   doesn't work to test if an objectStore has a keyPath or not. You 
   instead need to check
  
   if (myObjectStore.keyPath != null) {
     ...
   }
  
   or
  
   if (typeof myObjectStore.keyPath == string) {
     ...
   }
  
   Hence the isSet suggestion.
  
   Though I also realized after talking to Ben that empty keyPaths 
   show up in indexes too. Consider creating a objectStore which 
   maps peoples names to email addresses. Then you can create an 
   index when does the opposite mapping, or which ensures that 
   email
 addresses are unique:
  
   var store = db.createObjectStore(people); var index = 
   store.createIndex(reverse, , { unique: true }); 
   store.add(john@email.com, John Doe); 
   store.add(m...@smith.org, Mike Smith);
  
   store.get(John Doe).onsuccess = function(e) {
     alert(John's email is  + e.target.result); } 
  index.getKey(m...@smith.org).onsuccess = function(e) {
     alert(m...@smith.org is owned by  + e.target.result); }
  
   Are people proposing we remove empty keyPaths here too?
  
   / Jonas
  
   Yes, I'm proposing removing empty string KeyPaths all together to 
   avoid
  confusion.
   I would like to know how often you expect developers to follow 
   this pattern instead of using objects.  Our believe is that 
   objects will be the main value stored in object stores instead of single 
   values.
  
   Supporting keyPath with empty strings brings up all kinds of side 
   effects.
  For example:
  
   var store = db.createObjectStore(people); var index = 
   store.createIndex(reverse, , { unique: true });
   store.add({email: john@email.com}, John Doe);
   store.add({email: m...@smith.org},Mike Smith);
  
   What should happen in this case, do we throw an exception?
 
  This doesn't seem any different from
 
  var store = db.createObjectStore(people); var index = 
  store.createIndex(reverse, x, { unique: true }); store.add({ x: {email:
  john@email.com} }, John Doe); store.add({ x: {email:
  m...@smith.org} },Mike Smith);
 
  IIRC we decided a while ago that indexes do not add constraints. I.e.
  that if the keyPath for an index doesn't yield a valid key, then 
  the index simply doesn't get an entry pointing to newly stored value.
 
  So I don't really see that empty keyPaths bring up any special cases.
  The only special case we have in Firefox for empty keyPaths (apart 
  from the keyPath evaluation code itself) is the code that throws an 
  exception if you try to create an objectStore with an empty keyPath 
  and a
 key generator.
 
   Having some type of flag seems more promising for object stores.
   However, we still need to figure out how to deal with Indexes on 
   sets, do
  we pass another flag to support the indexes on sets?  If we do 
  that, then what do we do with the keyPath parameter to an index.
   It seems we're overloading the functionality of these methods to 
   support
  different patterns.
 
  Indeed, supporting the same use cases but using something other 
  than empty key paths gets pretty messy 

Re: [indexeddb] Do we need to support keyPaths with an empty string?

[Jonas Sicking]

On Fri, Jan 20, 2012 at 3:38 PM, Israel Hilerio isra...@microsoft.com wrote:
 On Friday, January 20, 2012 2:31 PM, Jonas Sicking wrote:
 On Fri, Jan 20, 2012 at 12:23 PM, ben turner bent.mozi...@gmail.com wrote:
  Mozilla is fine with removing the special |keyPath:| behavior.
  Please note that this will also mean that step 1 of the algorithm here
 
 
  http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-f
  or-extracting-a-key-from-a-value-using-a-key-path
 
  will need to change.
 
  We do want to continue to allow set behavior without specifying the
  key twice, though, so we would propose adding an additional option to
  createObjectStore to accomplish this:
 
   // Old way:
   var set = db.createObjectStore(mySet, { keyPath: });
   set.put(keyValue);
 
   // New way:
   var set = db.createObjectStore(mySet, { isSet: true });
   set.put(keyValue);
 
  (We are not in love with isSet, better names are highly encouraged!)
 
  What do you all think? This would allow us to continue to support nice
  set behavior without making the empty string magic.

 I actually think that the current behavior that we have is pretty 
 consistent. Any
 time you give the keyPath property a string we create an objectStore with a
 keyPath. And any time you have an objectStore with a keyPath you are not
 allowed to pass an explicit key since the key is gotten from the keyPath. 
 There's
 no special handling of empty strings happening.

 But I do agree that it can be somewhat confusing to tell /null/undefined 
 apart
 since they are all falsy. In particular, an expression like

 if (myObjectStore.keyPath) {
   ...
 }

 doesn't work to test if an objectStore has a keyPath or not. You instead 
 need to
 check

 if (myObjectStore.keyPath != null) {
   ...
 }

 or

 if (typeof myObjectStore.keyPath == string) {
   ...
 }

 Hence the isSet suggestion.

 Though I also realized after talking to Ben that empty keyPaths show up in
 indexes too. Consider creating a objectStore which maps peoples names to
 email addresses. Then you can create an index when does the opposite
 mapping, or which ensures that email addresses are unique:

 var store = db.createObjectStore(people); var index =
 store.createIndex(reverse, , { unique: true });
 store.add(john@email.com, John Doe); store.add(m...@smith.org,
 Mike Smith);

 store.get(John Doe).onsuccess = function(e) {
   alert(John's email is  + e.target.result); }
 index.getKey(m...@smith.org).onsuccess = function(e) {
   alert(m...@smith.org is owned by  + e.target.result); }

 Are people proposing we remove empty keyPaths here too?

 / Jonas

 Yes, I'm proposing removing empty string KeyPaths all together to avoid 
 confusion.
 I would like to know how often you expect developers to follow this pattern
 instead of using objects.  Our believe is that objects will be the main value 
 stored in object stores
 instead of single values.

 Supporting keyPath with empty strings brings up all kinds of side effects. 
 For example:

 var store = db.createObjectStore(people);
 var index = store.createIndex(reverse, , { unique: true });
 store.add({email: john@email.com}, John Doe);
 store.add({email: m...@smith.org},Mike Smith);

 What should happen in this case, do we throw an exception?

This doesn't seem any different from

var store = db.createObjectStore(people);
var index = store.createIndex(reverse, x, { unique: true });
store.add({ x: {email: john@email.com} }, John Doe);
store.add({ x: {email: m...@smith.org} },Mike Smith);

IIRC we decided a while ago that indexes do not add constraints. I.e.
that if the keyPath for an index doesn't yield a valid key, then the
index simply doesn't get an entry pointing to newly stored value.

So I don't really see that empty keyPaths bring up any special cases.
The only special case we have in Firefox for empty keyPaths (apart
from the keyPath evaluation code itself) is the code that throws an
exception if you try to create an objectStore with an empty keyPath
and a key generator.

 Having some type of flag seems more promising for object stores.  However, we 
 still need to figure out how to deal with
 Indexes on sets, do we pass another flag to support the indexes on sets?  If 
 we do that, then what do we do with the keyPath parameter to an index.
 It seems we're overloading the functionality of these methods to support 
 different patterns.

Indeed, supporting the same use cases but using something other than
empty key paths gets pretty messy for indexes. If we want to keep
supporting these use cases (which I personally do), then I think using
empty key paths is the cleanest solution.

Really the only downside that I see is the somewhat non-intuitive
objectStore.keyPath != null check. But I'm not convinced that this
is something that people will run in to a lot given that the main
use-case that I can think of is generic code which visualize a
indexedDB database for developers.

/ Jonas

RE: [indexeddb] Do we need to support keyPaths with an empty string?

[Israel Hilerio]

Any updates on this thread?  Odin from Opera prefers the FailFast method we've 
been discussing. We're in the process of cleaning some issues and would like to 
get this resolved ASAP.  If we believe the current implementation in Firefox 
and Chrome is the way to go, I'm okay with it but I would like to know how we 
explain it to developers.



Thanks,



Israel


On Wednesday, January 18, 2012 3:55 PM, Israel Hilerio wrote:
Based on our retesting of Aurora and Canary, this is the behavior we're seeing:

When a null or undefined keyPath is provided to the createObjectStore API, you 
can add values to an Object Store as long as a key is specified during the 
execution of the Add API.  Not providing a key for the Add API will throw a 
DATA_ERR.

Providing an empty string keyPath to the createObjectStore produces the 
opposite behavior.  The Add API works as long as you don't provide any value 
for the key.  I'm assuming that the value is used as the key value and that is 
the reason why using an object as the value fails.

This difference in behavior seems strange to me.  I would expect the behavior 
to be the same between a keyPath value of empty string, null, and undefined.  
How do you explain developers the reasons for the differences?  Is this the 
behavior we want to support moving forward?

Israel

On Wednesday, January 18, 2012 2:08 PM, Joshua Bell wrote:
On Wed, Jan 18, 2012 at 1:51 PM, ben turner 
bent.mozi...@gmail.commailto:bent.mozi...@gmail.com wrote:
On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio 
isra...@microsoft.commailto:isra...@microsoft.com wrote:
 We tested on Firefox 8.0.1

Ah, ok. We made lots of big changes to key handling that will be in 11
I think. If you're curious I would recommend retesting with an aurora
build from https://www.mozilla.org/en-US/firefox/aurora.

Similarly, we've made lots of IDB-related fixes in Chrome 16 (stable), 17 
(beta) and 18 (canary).

RE: [indexeddb] Do we need to support keyPaths with an empty string?

[Israel Hilerio]

Jeremy,

What you're saying about the discrepancies between empty string, null, and 
undefined make a lot of sense.  That is one of the reasons for this proposal, 
to stop adding to the confusion.
I also agree with you that we should support the set scenario and that this 
can be accomplished without having to support keypaths with empty strings, 
null, or undefined values.

I would like to hear from someone at Mozilla before we remove this from the 
spec.
Thanks,

Israel

On Friday, January 20, 2012 10:48 AM, Joshua Bell wrote:
rom: jsb...@google.com [mailto:jsb...@google.com] On Behalf Of Joshua Bell
Sent: Friday, January 20, 2012 10:48 AM
To: Israel Hilerio
Cc: Odin Hørthe Omdal; Jonas Sicking (jo...@sicking.cc); ben turner 
(bent.mozi...@gmail.com); Adam Herchenroether; David Sheldon; 
public-webapps@w3.org
Subject: Re: [indexeddb] Do we need to support keyPaths with an empty string?

Empty strings, null, and undefined are all dangerous traps for the unwary in 
JavaScript already; all are falsy, some compare equal with ==, all ToString 
differently, some ToNumber differently. Personally, I try not to make any 
assumptions about how an API will respond to these inputs and approach with 
extreme caution.

IMHO the set scenario is a valid use case, but that can be satisfied by 
specifying no key path and repeating the value during the put/add call, e.g. 
store.put(value, value). Therefore, I'm not opposed to removing empty string as 
a valid key path, but don't see it as particularly confusing, either.

On Fri, Jan 20, 2012 at 9:58 AM, Israel Hilerio 
isra...@microsoft.commailto:isra...@microsoft.com wrote:

Any updates on this thread?  Odin from Opera prefers the FailFast method we've 
been discussing. We're in the process of cleaning some issues and would like to 
get this resolved ASAP.  If we believe the current implementation in Firefox 
and Chrome is the way to go, I'm okay with it but I would like to know how we 
explain it to developers.



Thanks,



Israel


On Wednesday, January 18, 2012 3:55 PM, Israel Hilerio wrote:
Based on our retesting of Aurora and Canary, this is the behavior we're seeing:

When a null or undefined keyPath is provided to the createObjectStore API, you 
can add values to an Object Store as long as a key is specified during the 
execution of the Add API.  Not providing a key for the Add API will throw a 
DATA_ERR.

Providing an empty string keyPath to the createObjectStore produces the 
opposite behavior.  The Add API works as long as you don't provide any value 
for the key.  I'm assuming that the value is used as the key value and that is 
the reason why using an object as the value fails.

This difference in behavior seems strange to me.  I would expect the behavior 
to be the same between a keyPath value of empty string, null, and undefined.  
How do you explain developers the reasons for the differences?  Is this the 
behavior we want to support moving forward?

Israel

On Wednesday, January 18, 2012 2:08 PM, Joshua Bell wrote:
On Wed, Jan 18, 2012 at 1:51 PM, ben turner 
bent.mozi...@gmail.commailto:bent.mozi...@gmail.com wrote:
On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio 
isra...@microsoft.commailto:isra...@microsoft.com wrote:
 We tested on Firefox 8.0.1

Ah, ok. We made lots of big changes to key handling that will be in 11
I think. If you're curious I would recommend retesting with an aurora
build from https://www.mozilla.org/en-US/firefox/aurora.

Similarly, we've made lots of IDB-related fixes in Chrome 16 (stable), 17 
(beta) and 18 (canary).

Re: [indexeddb] Do we need to support keyPaths with an empty string?

[ben turner]

Mozilla is fine with removing the special |keyPath:| behavior.
Please note that this will also mean that step 1 of the algorithm here

  
http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-extracting-a-key-from-a-value-using-a-key-path

will need to change.

We do want to continue to allow set behavior without specifying the
key twice, though, so we would propose adding an additional option to
createObjectStore to accomplish this:

  // Old way:
  var set = db.createObjectStore(mySet, { keyPath: });
  set.put(keyValue);

  // New way:
  var set = db.createObjectStore(mySet, { isSet: true });
  set.put(keyValue);

(We are not in love with isSet, better names are highly encouraged!)

What do you all think? This would allow us to continue to support nice
set behavior without making the empty string magic.

-Ben

Re: [indexeddb] Do we need to support keyPaths with an empty string?

[Jonas Sicking]

On Fri, Jan 20, 2012 at 12:23 PM, ben turner bent.mozi...@gmail.com wrote:
 Mozilla is fine with removing the special |keyPath:| behavior.
 Please note that this will also mean that step 1 of the algorithm here

  http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-for-extracting-a-key-from-a-value-using-a-key-path

 will need to change.

 We do want to continue to allow set behavior without specifying the
 key twice, though, so we would propose adding an additional option to
 createObjectStore to accomplish this:

  // Old way:
  var set = db.createObjectStore(mySet, { keyPath: });
  set.put(keyValue);

  // New way:
  var set = db.createObjectStore(mySet, { isSet: true });
  set.put(keyValue);

 (We are not in love with isSet, better names are highly encouraged!)

 What do you all think? This would allow us to continue to support nice
 set behavior without making the empty string magic.

I actually think that the current behavior that we have is pretty
consistent. Any time you give the keyPath property a string we create
an objectStore with a keyPath. And any time you have an objectStore
with a keyPath you are not allowed to pass an explicit key since the
key is gotten from the keyPath. There's no special handling of empty
strings happening.

But I do agree that it can be somewhat confusing to tell
/null/undefined apart since they are all falsy. In particular, an
expression like

if (myObjectStore.keyPath) {
  ...
}

doesn't work to test if an objectStore has a keyPath or not. You
instead need to check

if (myObjectStore.keyPath != null) {
  ...
}

or

if (typeof myObjectStore.keyPath == string) {
  ...
}

Hence the isSet suggestion.

Though I also realized after talking to Ben that empty keyPaths show
up in indexes too. Consider creating a objectStore which maps peoples
names to email addresses. Then you can create an index when does the
opposite mapping, or which ensures that email addresses are unique:

var store = db.createObjectStore(people);
var index = store.createIndex(reverse, , { unique: true });
store.add(john@email.com, John Doe);
store.add(m...@smith.org, Mike Smith);

store.get(John Doe).onsuccess = function(e) {
  alert(John's email is  + e.target.result);
}
index.getKey(m...@smith.org).onsuccess = function(e) {
  alert(m...@smith.org is owned by  + e.target.result);
}

Are people proposing we remove empty keyPaths here too?

/ Jonas

RE: [indexeddb] Do we need to support keyPaths with an empty string?

[Israel Hilerio]

On Friday, January 20, 2012 2:31 PM, Jonas Sicking wrote:
 On Fri, Jan 20, 2012 at 12:23 PM, ben turner bent.mozi...@gmail.com wrote:
  Mozilla is fine with removing the special |keyPath:| behavior.
  Please note that this will also mean that step 1 of the algorithm here
 
 
  http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#dfn-steps-f
  or-extracting-a-key-from-a-value-using-a-key-path
 
  will need to change.
 
  We do want to continue to allow set behavior without specifying the
  key twice, though, so we would propose adding an additional option to
  createObjectStore to accomplish this:
 
   // Old way:
   var set = db.createObjectStore(mySet, { keyPath: });
   set.put(keyValue);
 
   // New way:
   var set = db.createObjectStore(mySet, { isSet: true });
   set.put(keyValue);
 
  (We are not in love with isSet, better names are highly encouraged!)
 
  What do you all think? This would allow us to continue to support nice
  set behavior without making the empty string magic.
 
 I actually think that the current behavior that we have is pretty consistent. 
 Any
 time you give the keyPath property a string we create an objectStore with a
 keyPath. And any time you have an objectStore with a keyPath you are not
 allowed to pass an explicit key since the key is gotten from the keyPath. 
 There's
 no special handling of empty strings happening.
 
 But I do agree that it can be somewhat confusing to tell /null/undefined 
 apart
 since they are all falsy. In particular, an expression like
 
 if (myObjectStore.keyPath) {
   ...
 }
 
 doesn't work to test if an objectStore has a keyPath or not. You instead need 
 to
 check
 
 if (myObjectStore.keyPath != null) {
   ...
 }
 
 or
 
 if (typeof myObjectStore.keyPath == string) {
   ...
 }
 
 Hence the isSet suggestion.
 
 Though I also realized after talking to Ben that empty keyPaths show up in
 indexes too. Consider creating a objectStore which maps peoples names to
 email addresses. Then you can create an index when does the opposite
 mapping, or which ensures that email addresses are unique:
 
 var store = db.createObjectStore(people); var index =
 store.createIndex(reverse, , { unique: true });
 store.add(john@email.com, John Doe); store.add(m...@smith.org,
 Mike Smith);
 
 store.get(John Doe).onsuccess = function(e) {
   alert(John's email is  + e.target.result); }
 index.getKey(m...@smith.org).onsuccess = function(e) {
   alert(m...@smith.org is owned by  + e.target.result); }
 
 Are people proposing we remove empty keyPaths here too?
 
 / Jonas

Yes, I'm proposing removing empty string KeyPaths all together to avoid 
confusion.
I would like to know how often you expect developers to follow this pattern
instead of using objects.  Our believe is that objects will be the main value 
stored in object stores 
instead of single values.

Supporting keyPath with empty strings brings up all kinds of side effects. For 
example:

var store = db.createObjectStore(people); 
var index = store.createIndex(reverse, , { unique: true });
store.add({email: john@email.com}, John Doe); 
store.add({email: m...@smith.org},Mike Smith);

What should happen in this case, do we throw an exception? This is the scenario 
we see in FF and Chrome.
I don't believe it will be obvious to developers that this functionality 
behaves differently depending on the 
value being stored.

Having some type of flag seems more promising for object stores.  However, we 
still need to figure out how to deal with 
Indexes on sets, do we pass another flag to support the indexes on sets?  If we 
do that, then what do we do with the keyPath parameter to an index.
It seems we're overloading the functionality of these methods to support 
different patterns.

Israel

Re: [indexeddb] Do we need to support keyPaths with an empty string?

[Odin Hørthe Omdal]

On Wed, 18 Jan 2012 22:16:29 +0100, Israel Hilerio isra...@microsoft.com  
wrote:


Given the different behaviors, I wonder if the use case you described  
below (i.e. set scenario) is worth supporting.  Not supporting keyPath =  
undefined, null, and “” seem to provide a more consistent and clean  
story.  Returning an exception when a developer creates an Object Store  
with a keyPath of null, undefined, or empty string will provide a  
FailFast API.


What do you think?


I prefer this option.

Making the throw and the cause of it closer. It feels more consistent, and  
requires less understanding of all details of IDB to understand. Web  
authors doesn't always read the spec faithfully.


--
Odin Hørthe Omdal · Core QA, Opera Software · http://opera.com /

RE: [indexeddb] Do we need to support keyPaths with an empty string?

[Israel Hilerio]

On Friday, January 13, 2012 1:33 PM, Israel Hilerio wrote:
 Given the changes that Jonas made to the spec, on which other scenarios do we
 expect developers to specify a keyPath with an empty string (i.e. keyPath = 
 )?
 Do we still need to support this or can we just throw if this takes place.  I
 reopened bug #14985 [1] to reflect this.  Jonas or anyone else could you 
 please
 clarify?
 
 Israel
 [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=14985

Any updates!  I expect this to apply to all of the following scenarios:
var obj = { keyPath : null };
var obj = { keyPath : undefined };
var obj = { keyPath :  }; 

If you guys agree, we can update the spec.

Israel

Re: [indexeddb] Do we need to support keyPaths with an empty string?

[Joshua Bell]

On Wed, Jan 18, 2012 at 11:30 AM, Israel Hilerio isra...@microsoft.comwrote:

 On Friday, January 13, 2012 1:33 PM, Israel Hilerio wrote:
  Given the changes that Jonas made to the spec, on which other scenarios
 do we
  expect developers to specify a keyPath with an empty string (i.e.
 keyPath = )?
  Do we still need to support this or can we just throw if this takes
 place.  I
  reopened bug #14985 [1] to reflect this.  Jonas or anyone else could you
 please
  clarify?
 
  Israel
  [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=14985

 Any updates!  I expect this to apply to all of the following scenarios:
 var obj = { keyPath : null };
 var obj = { keyPath : undefined };
 var obj = { keyPath :  };


If I'm reading your concern right, the wording in the spec (and Jonas'
comment in the bug) hints at the scenario of using the value as its own key
for object stores as long as autoIncrement is false, e.g.

store = db.createObjectStore(my-store, {keyPath: });
store.put(abc); // same as store.put(abc, abc)
store.put([123]); // same as store.put([123], [123]);
store.put({foo: bar}); // keyPath yields value which is not a valid key,
so should throw

Chrome supports this today (apart from a known bug with the error case).

One scenario would be using an object store to implement a Set, which seems
like a valid use case if not particularly exciting.

RE: [indexeddb] Do we need to support keyPaths with an empty string?

[Israel Hilerio]

Joshua,

We did some testing in FF and Chrome and found different behaviors:

*With keyPath: undefined or null.  In this scenario, FF and Chrome 
fails when executing add(foobar) without a key value.  However, Chrome allows 
you to add a valid key value or an object if you specify a key (i.e. 
add(foobar,1); ).  Firefox doesn't work in either case.  You end up with what 
appears to be a broken Object Store.

*With keyPath:  or empty string.  In this scenario, FF fails when 
executing add(foobar) without a key, but succeeds if you supply a key value.  
It doesn't matter if the value being added is a valid key or an object.  Chrome 
succeeds when executing add(foobar) but fails when the value being added is 
an object (i.e. add({foo: bar}); ).  Chrome also fails when you specify a key 
value even if the value being added is a valid key value (i.e. add(foobar, 
1); ).

Given the different behaviors, I wonder if the use case you described below 
(i.e. set scenario) is worth supporting.  Not supporting keyPath = undefined, 
null, and  seem to provide a more consistent and clean story.  Returning an 
exception when a developer creates an Object Store with a keyPath of null, 
undefined, or empty string will provide a FailFast API.

What do you think?

Israel

On Wednesday, January 18, 2012 12:08 PM Joshua Bell wrote:
On Wed, Jan 18, 2012 at 11:30 AM, Israel Hilerio 
isra...@microsoft.commailto:isra...@microsoft.com wrote:
On Friday, January 13, 2012 1:33 PM, Israel Hilerio wrote:
 Given the changes that Jonas made to the spec, on which other scenarios do we
 expect developers to specify a keyPath with an empty string (i.e. keyPath = 
 )?
 Do we still need to support this or can we just throw if this takes place.  I
 reopened bug #14985 [1] to reflect this.  Jonas or anyone else could you 
 please
 clarify?

 Israel
 [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=14985
Any updates!  I expect this to apply to all of the following scenarios:
var obj = { keyPath : null };
var obj = { keyPath : undefined };
var obj = { keyPath :  };

If I'm reading your concern right, the wording in the spec (and Jonas' comment 
in the bug) hints at the scenario of using the value as its own key for object 
stores as long as autoIncrement is false, e.g.

store = db.createObjectStore(my-store, {keyPath: });
store.put(abc); // same as store.put(abc, abc)
store.put([123]); // same as store.put([123], [123]);
store.put({foo: bar}); // keyPath yields value which is not a valid key, so 
should throw

Chrome supports this today (apart from a known bug with the error case).

One scenario would be using an object store to implement a Set, which seems 
like a valid use case if not particularly exciting.

Re: [indexeddb] Do we need to support keyPaths with an empty string?

[ben turner]

On Wed, Jan 18, 2012 at 1:16 PM, Israel Hilerio isra...@microsoft.com wrote:

 We did some testing in FF and Chrome and found different behaviors:

Hi Israel,

Which version of Firefox did you test with?

Thanks,
Ben

RE: [indexeddb] Do we need to support keyPaths with an empty string?

[Israel Hilerio]

On Wednesday, January 18, 2012 1:27 PM, ben turner wrote:
 On Wed, Jan 18, 2012 at 1:16 PM, Israel Hilerio isra...@microsoft.com
 wrote:
 
  We did some testing in FF and Chrome and found different behaviors:
 
 Hi Israel,
 
 Which version of Firefox did you test with?
 
 Thanks,
 Ben

We tested on Firefox 8.0.1

Israel

Re: [indexeddb] Do we need to support keyPaths with an empty string?

[ben turner]

On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio isra...@microsoft.com wrote:
 We tested on Firefox 8.0.1

Ah, ok. We made lots of big changes to key handling that will be in 11
I think. If you're curious I would recommend retesting with an aurora
build from https://www.mozilla.org/en-US/firefox/aurora.

Thanks for the info!
-Ben

Re: [indexeddb] Do we need to support keyPaths with an empty string?

[Joshua Bell]

On Wed, Jan 18, 2012 at 1:51 PM, ben turner bent.mozi...@gmail.com wrote:

 On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio isra...@microsoft.com
 wrote:
  We tested on Firefox 8.0.1

 Ah, ok. We made lots of big changes to key handling that will be in 11
 I think. If you're curious I would recommend retesting with an aurora
 build from https://www.mozilla.org/en-US/firefox/aurora.


Similarly, we've made lots of IDB-related fixes in Chrome 16 (stable), 17
(beta) and 18 (canary).

RE: [indexeddb] Do we need to support keyPaths with an empty string?

[Israel Hilerio]

Based on our retesting of Aurora and Canary, this is the behavior we're seeing:

When a null or undefined keyPath is provided to the createObjectStore API, you 
can add values to an Object Store as long as a key is specified during the 
execution of the Add API.  Not providing a key for the Add API will throw a 
DATA_ERR.

Providing an empty string keyPath to the createObjectStore produces the 
opposite behavior.  The Add API works as long as you don't provide any value 
for the key.  I'm assuming that the value is used as the key value and that is 
the reason why using an object as the value fails.

This difference in behavior seems strange to me.  I would expect the behavior 
to be the same between a keyPath value of empty string, null, and undefined.  
How do you explain developers the reasons for the differences?  Is this the 
behavior we want to support moving forward?

Israel

On Wednesday, January 18, 2012 2:08 PM, Joshua Bell wrote:
On Wed, Jan 18, 2012 at 1:51 PM, ben turner 
bent.mozi...@gmail.commailto:bent.mozi...@gmail.com wrote:
On Wed, Jan 18, 2012 at 1:40 PM, Israel Hilerio 
isra...@microsoft.commailto:isra...@microsoft.com wrote:
 We tested on Firefox 8.0.1

Ah, ok. We made lots of big changes to key handling that will be in 11
I think. If you're curious I would recommend retesting with an aurora
build from https://www.mozilla.org/en-US/firefox/aurora.

Similarly, we've made lots of IDB-related fixes in Chrome 16 (stable), 17 
(beta) and 18 (canary).