This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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?
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.
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.