This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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] }
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.
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.
I added examples to 3.1.3 Keys, as outlined in this bug and the mails.