This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 15927 - [IndexedDB] Allowing "." and " " in keys specified using keyPath
Summary: [IndexedDB] Allowing "." and " " in keys specified using keyPath
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2012-02-07 14:18 UTC by Odin Hørthe Omdal
Modified: 2012-02-14 16:35 UTC (History)
3 users (show)

See Also:


Description Odin Hørthe Omdal 2012-02-07 14:18:32 UTC
I've been trying to find any decision/answer about IndexedDB keypath and "." to seperate objects.

It's very possible I could get data from a third party that has:

   obj["my.key"] = thing

and I'd want to have a keypath that accesses  my.key  like that, so NOT like:

  obj = { my: { key: thing } }

Similarly about spaces:  obj["my key"] = "blabla"

It would introduce some extra complexity to support this, sure, and it might not be worth it at all, but has it been discussed on its own?
Comment 1 Jonas Sicking (Not reading bugmail) 2012-02-14 04:47:47 UTC
I can't say with 100% certainty but I think we discussed this a long time ago.

My opinion is that this is a known by for now acceptable limitation. KeyPaths have a number of limitations, like unable to access properties in arrays or do even basic processing like adding values.

Ultimately I think we'll end up having to add something like complex keyPath support which will take care of these limitations. See also bug 10000.
Comment 2 Odin Hørthe Omdal 2012-02-14 16:35:30 UTC
OK. Not for this version then.

It's a bit arbitrary to only allow valid javascript identifiers to be used as indexes, but sometimes that's just the way the world works.