Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value

On Tue, Jan 24, 2012 at 11:38 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Jan 24, 2012 at 8:43 AM, Joshua Bell <jsbell@chromium.org> wrote:
> > On Tue, Jan 24, 2012 at 2:21 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> >> What happens if a value "higher up" in the keyPath is not an object:
> >> store = db.createObjectStore("os", { keyPath: "a.b.c", autoIncrement:
> true
> >> });
> >> store.put({ a: "str" });
> >> Here there not only is nowhere to directly store the new value. We
> >> also can't simply insert the missing objects since we can't add a "b"
> >> property to the value "str". Exact same scenario appears if you
> >> replace "str" with a 1 or null.
> >> What we do in Firefox is to throw a DataError exception.
> >> Another example of this is simply
> >> store = db.createObjectStore("os", { keyPath: "a", autoIncrement: true
> });
> >> store.put("str");
> >
> > Chrome currently defers setting the new value until the transaction
> executes
> > the asynchronous request, and thus doesn't raise an exception but fails
> the
> > request. I agree that doing this at the time of the call makes more sense
> > and is more consistent and predictable. If there's consensus here I'll
> file
> > a bug against Chromium.
>
> Awesome!


One clarification here: I believe the key generation logic must run as part
of the asynchronous storage operation within the request so the key
generator state is contained within the transaction (i.e. an aborted
transaction would reset the key generator state for stores in scope).
Therefore inserting the key into the value must still wait until the
request is processed. That implies that at call time the value should be
checked to ensure the generated key can be inserted, and then at storage
operation time the value is actually updated.

Does this match others' interpretation?