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

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

You can normally insert with a supplied key providing it is unique.

Cheers,
Keean.



On 10 November 2010 22:07, Jonas Sicking <jonas@sicking.cc> wrote:

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