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

On Wed, Jan 25, 2012 at 11:38 AM, Joshua Bell <jsbell@chromium.org> wrote:
> 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?

Conceptually I agree. In Firefox we do use a different approach
though. We actually insert a dummy value synchronously and then
serialize and send off to the database thread. But when we serialize
we do that in such a way that we know where in the serialization the
dummy-value resides. That way the database thread can update the value
to write the generated key into the serialized value.

But the generated key is definitely generated on the database-thread
at least in the general case.

This does bring up another thing that is undefined though, which is
the specifics of key generation. I'll start a separate thread on that.

/ Jonas

Received on Wednesday, 25 January 2012 19:50:36 UTC