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 > > >Received on Thursday, 20 January 2011 13:00:57 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:16 UTC