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: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 10 Nov 2010 14:07:58 -0800
Message-ID: <AANLkTinAAwP1xBoXZXYPAjUyFsp6_UYg1aRyc=5+qk3N@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Pablo Castro <Pablo.Castro@microsoft.com>, "bugzilla@jessica.w3.org" <bugzilla@jessica.w3.org>, "public-webapps@w3.org" <public-webapps@w3.org>
On Wed, Nov 10, 2010 at 1:50 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro
> <Pablo.Castro@microsoft.com> wrote:
>>
>> 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.
>
> It's relatively common for me to need to supply a manual value for an
> id field that's automatically generated when working with databases,
> and I don't see any particular reason that my situation would change
> if using IndexedDB.  So I think that a manually-supplied key should be
> kept.

I'm fine with either solution here. My database experience is too weak
to have strong opinions on this matter.

What do databases usually do with columns that use autoincrement but a
value is still supplied? My recollection is that that is generally
allowed?

>>>> 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.
>
> Agreed.

Works for me.

>>>> 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.
>
> Agreed.

Works for me.

Actually, we could go even further and disallow paths entirely, and
just allow a property name. That is what the firefox implementation
currently does. That also sidesteps the issue of missing parents.

/ Jonas
Received on Wednesday, 10 November 2010 22:08:48 GMT

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