- From: <bugzilla@jessica.w3.org>
- Date: Tue, 09 Nov 2010 01:07:16 +0000
- To: public-webapps@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11270 Summary: Interaction between in-line keys and key generators Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.null@w3.org ReportedBy: jonas@sicking.cc QAContact: member-webapi-cvs@w3.org CC: mike@w3.org, public-webapps@w3.org 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] } -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Tuesday, 9 November 2010 01:07:18 UTC