Some more corner cases: what does a keyPath of "" mean?  Does it mean that we index the value itself or is it an error?  What if the value being inserted is not an object?  If it's an array and keyPath is "length" do we allow that?  Etc.

(In reply to comment #1)
> Some more corner cases: what does a keyPath of "" mean?  Does it mean that we
> index the value itself or is it an error?  What if the value being inserted is
> not an object?  If it's an array and keyPath is "length" do we allow that? 
> Etc.

The meaning of "" is defined in the description of createObjectStore as:

If null path is specified, then the object store created will not have a key path and will use out-of-line keys.

The description should be updated to refer to the empty path instead of the null path.

I am not in favor (In reply to comment #0)
> KeyPaths and their underspecification has come up in several threads, but
> especially "[IndexedDB] KeyPaths and missing properties" [1].  We need to have
> normative text describing how to parse keyPath and how a keyPath maps to
> properties of a value.  We need to decide whether we want to allow explicit
> index management and whether we want this to be done via ObjectStore's
> add/modify/addOrModify or whether we want to have methods hanging off of each
> index to do this.  We need to decide what to do if the key corresponding to a
> keyPath doesn't exist (insert null, insert nothing, or raise error).  This list
> may be incomplete.
> 
> [1] http://www.mail-archive.com/public-webapps@w3.org/msg08862.html

Removing the explicit index management does not seem like a bug. Let us focus on fixing the spec rather than making scoping decisions at this time.

(In reply to comment #2)
> (In reply to comment #1)
> > Some more corner cases: what does a keyPath of "" mean?  Does it mean that we
> > index the value itself or is it an error?  What if the value being inserted is
> > not an object?  If it's an array and keyPath is "length" do we allow that? 
> > Etc.
> 
> The meaning of "" is defined in the description of createObjectStore as:
> 
> If null path is specified, then the object store created will not have a key
> path and will use out-of-line keys.
> 
> The description should be updated to refer to the empty path instead of the
> null path.

Null is different than the empty string.  I still believe it's underspecified.  If "" and null are supposed to have the same behavior, then it should be specified as such...and maybe "[NullAs=Null]" is not the most clear since I'd expect that to be there when null has its own meaning.


(In reply to comment #3)
> I am not in favor (In reply to comment #0)
> > KeyPaths and their underspecification has come up in several threads, but
> > especially "[IndexedDB] KeyPaths and missing properties" [1].  We need to have
> > normative text describing how to parse keyPath and how a keyPath maps to
> > properties of a value.  We need to decide whether we want to allow explicit
> > index management and whether we want this to be done via ObjectStore's
> > add/modify/addOrModify or whether we want to have methods hanging off of each
> > index to do this.  We need to decide what to do if the key corresponding to a
> > keyPath doesn't exist (insert null, insert nothing, or raise error).  This list
> > may be incomplete.
> > 
> > [1] http://www.mail-archive.com/public-webapps@w3.org/msg08862.html
> 
> Removing the explicit index management does not seem like a bug. Let us focus
> on fixing the spec rather than making scoping decisions at this time.

It's a large amount of API surface area for a few small use cases.  Other proposals for how to serve those use cases in lighter weight (API wise and usage wise) fashion have been proposed that also make it harder to get the database into an inconsistent state if we decide those use cases are important.

I'm fine with you splitting the question of whether we have explicit indexes into its own bug, but it definitely is something that needs to be addressed sooner rather than later.

*** This bug has been marked as a duplicate of bug 11269 ***