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

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.


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


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

~TJ

Received on Wednesday, 10 November 2010 21:51:14 UTC