11270 2010-11-09 01:07:16 +0000 Interaction between in-line keys and key generators 2015-04-09 21:51:36 +0000 1 1 1 Unclassified WebAppsWG Indexed Database API unspecified PC All RESOLVED FIXED P2 normal --- 1 jonas dave.null eliotgra jorlow mike pablo.castro public-webapps timm public-webapps-bugzilla oldest_to_newest 42298 0 jonas 2010-11-09 01:07:16 +0000 This is related to, and affected by, bug 9832 and bug 11269. When adding a value to an object store which uses in-line keys and key generators keypaths are used to point out where a value should be *modified*. A key is generated and written to the stored value, and the location in the stored value is determined using the object store's keypath. So what happens if trying save in an object store which has the following keypath, the following value. (The generated key is 4): "foo.bar" { foo: {} } Here the resulting object is clearly { foo: { bar: 4 } } But what about "foo.bar" { foo: { bar: 10 } } Does this use the value 10 rather than generate a new key, does it throw an exception or does it store the value { foo: { bar: 4 } }? What happens if the property is missing several parents, such as "foo.bar.baz" { zip: {} } Does this throw or does it store { zip: {}, foo: { bar: { baz: 4 } } } If we end up allowing array indexes in key paths (like "foo[1].bar") what does the following keypath/object result in? "foo[0]" { foo: [10] } "foo[1]" { foo: [10] } "foo[5]" { foo: [10] } 42299 1 jonas 2010-11-09 01:12:36 +0000 Oh, something that definitely needs to be an error is "foo" 4 I.e. trying to set a property on a primitive value. But what about: "foo" [10] Technically speaking the structured clone format already supports serializing properties on arrays, but it still feels wrong. 48753 2 pablo.castro 2011-05-24 21:55:54 +0000 Here's my take on this. We can discuss in the list if any of these needs further details: >> But what about >> >> "foo.bar" >> { foo: { bar: 10 } } >> >> Does this use the value 10 rather than generate a new key, does it throw an exception or does it store the value { foo: { bar: 4 } }? It uses the value 10 (and fails if there is a constraint violation). This is just like when you explicitly specify a key value in a top-level keypath. >> What happens if the property is missing several parents, such as >> >> "foo.bar.baz" >> { zip: {} } >> >> Does this throw or does it store { zip: {}, foo: { bar: { baz: 4 } } } It creates all the parents until it can store the value. >> If we end up allowing array indexes in key paths (like "foo[1].bar") what does >> the following keypath/object result in? >> >> "foo[0]" >> { foo: [10] } >> >> "foo[1]" >> { foo: [10] } >> >> "foo[5]" >> { foo: [10] } These would probably be fine. The only thing I wouldn't do is to complete the array so it's not sparse (the spec doesn't allow sparse arrays to be keys). >> Oh, something that definitely needs to be an error is >> >> "foo" >> 4 >> >> I.e. trying to set a property on a primitive value. Agreed. >> But what about: >> >> "foo" >> [10] >> >> Technically speaking the structured clone format already supports serializing properties on arrays, but it still feels wrong. +1, too weird. 50980 3 eliotgra 2011-07-13 21:52:57 +0000 I added examples to 3.1.3 Keys, as outlined in this bug and the mails.