Re: [IndexedDB] Auto increment and spec inconsistency

Sounds good to me.  Please file a bug?

On Mon, Jan 17, 2011 at 5:06 PM, Hans Wennborg <hans@chromium.org> wrote:

> Reading http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html,
> there seems to be some inconsistency around how an object store with
> key generator is supposed to behave.
>
> In 5.1 Object Store Storage Operation, step 1 it says: "If store uses
> a key generator and key is undefined, set key to the next generated
> key. If store also uses in-line keys, then set the property in value
> pointed to by store's key path to the new value for key".
>
> But in the object store example in 3.3.3, there is the following:
>
> A second put operation will overwrite the record stored by the first
> put operation.
> var abraham = {id: 1, name: 'Abraham', number: '2107'};
> store.put(abraham);
>
> However, the way I read the specification, the key generator will
> generate the key 2, and then set the "id" property in the value to 2.
> So this operation does not at all overwrite the first record, and the
> next statement in the example: "Now when the object store is read with
> the same key, the result is different compared to the object read
> earlier." is false.
>
>
> It seems to me that for an object store with a key generator, it is
> never possible to specify the key for a put or add operation: Using a
> key parameter is disallowed (in 3.2.5 under "add" and "put"), and
> in-line keys get overwritten.
>
> This means that it is not possible to update a record with a put
> operation if the object store uses a key generator, which seems
> counter-intuitive to me.
>
> To me, it would make sense that:
>
> 1. If a user provides an explicit key to an operation on an object
> store that has a key generator, then the explicit key takes
> precedence, and the key generator doesn't do anything.
>
> 2. If a user provides an in-line key, then that key takes precedence,
> and the key generator doesn't do anything.
>
> I would be interested to read your thoughts about this.
>
> Thanks,
> Hans
>
>
>