Bug 15927 - [IndexedDB] Allowing "." and " " in keys specified using keyPath
[IndexedDB] Allowing "." and " " in keys specified using keyPath
Status: RESOLVED WONTFIX
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API
unspecified
PC Linux
: P2 normal
: ---
Assigned To: This bug has no owner yet - up for the taking
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 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.