>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 <[email protected]> wrote: > On Wed, Nov 10, 2010 at 1:50 PM, Tab Atkins Jr. <[email protected]> > wrote: > > On Wed, Nov 10, 2010 at 1:43 PM, Pablo Castro > > <[email protected]> wrote: > >> > >> From: [email protected] [mailto: > [email protected]] On Behalf Of [email protected] > >> 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 > >
