W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

RE: [Bug 11270] New: Interaction between in-line keys and key generators

From: Pablo Castro <Pablo.Castro@microsoft.com>
Date: Wed, 10 Nov 2010 21:43:32 +0000
To: "bugzilla@jessica.w3.org" <bugzilla@jessica.w3.org>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F753B2C401114141B426DB383C8885E0622BC7A9@TK5EX14MBXC124.redmond.corp.microsoft.com>

From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of bugzilla@jessica.w3.org
Sent: Monday, November 08, 2010 5:07 PM

>> 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 } }?

I suspect that all options are somewhat arbitrary here. I'll just propose that we error out to ensure that nobody has the wrong expectations about the implementation preserving the initial value. I would be open to other options except silently overwriting the initial value with a generated one, as that's likely to confuse folks.

>> 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 } } }

We should just complete the object with all the missing parents.

>> If we end up allowing array indexes in key paths (like "foo[1].bar") what does
>> the following keypath/object result in?

I think we can live without array indexing in keys for this round, it's probably best to just leave them out and only allow paths.

-pablo
Received on Wednesday, 10 November 2010 21:44:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:41 GMT