W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

IndexedDB: Key generators (autoIncrement) and Array-type key paths

From: Joshua Bell <jsbell@chromium.org>
Date: Wed, 11 Apr 2012 16:47:37 -0700
Message-ID: <CAD649j5tTCWemqdr_qUXW6nHOOkRTyZgDTJShneU9NE7oSeg6Q@mail.gmail.com>
To: public-webapps@w3.org
Something I'm not seeing covered by the spec - what should the behavior be
when inserting a value into an object store if the object store has a key
generator and the key path is an Array? Should this be supported, or is it
an error?

e.g. what is alerted:

var store = db.createObjectStore('store', { keyPath: ['id1', 'id2'],
autoIncrement: true });
store.put({name: 'Alice'});
store.count().onsuccess = function (e) {
alert(JSON.stringify(e.target.result)); };
store.openCursor().onsuccess = function (e) {
  var cursor = e.target.result;
  if (cursor) {
    alert(JSON.stringify(e.target.result.value));
    cursor.continue();
  }
};

I can imagine multiple outcomes:

1 then {"name": "Alice", "id1": 1}
1 then {"name": "Alice", "id1": 1, "id2": 1}
2 then {"name": "Alice", "id1": 1, "id2": 2} then {"name": "Alice", "id1":
1, "id2": 2}

But in none of these cases does evaluating the key path against the value
match the key. Therefore, I suspect this scenario should not be supported.

My reading of the spec:

3.2.4 "Database" / "createObjectStore" ... If keyPath is an Array, then
each item in the array is converted to a string. ... If ...
autoIncrement is set to true, and the keyPath parameter is ... specified to
an Array ...

So Array-type key paths are not explicitly ruled out on object stores; nor
is there a specific clause forbidding autoIncrement + Array-type key paths.

3.2.5 "Object Store" / "put" - an error should be thrown if ... The object
store uses in-line keys and the result of evaluating the object store's key
path yields a value and that value is not a valid key.

4.7 "steps for extracting a key from a value using a key
path"  If keyPath is an Array, then ... For each item in the keyPath Array
... Evaluate ... If the result of the previous step was not a valid key
path[1], then abort the overall algorithm and no value is returned.

So, in the example given, the put() is not prevented - the key path would
yield no value, which is fine.

5.1 "steps for storing a record into an object store" step 2: 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 invalue pointed to
by store's key path to the new value for key, as shown in the steps to
assign a key to a value using a key path.

4.13 "steps to assign a key to a value using a key path" is written
assuming the keyPath is a string.

So, by my reading something between 5.1 and 4.13 needs to be clarified if
this should be supported.

If we want to prevent this, the spec change would be:

OLD: If the optionalParameters parameter is specified, and autoIncrement is
set to true, and the keyPath parameter is specified to the empty string, or
specified to an Array and one of the items is an empty string, this
function must throw a InvalidAccessError exception.

NEW: If the optionalParameters parameter is specified, and autoIncrement is
set to true, and the keyPath parameter is specified to the empty string, or
specified to an Array, this function must throw
a InvalidAccessError exception.

[1] SPEC NIT: 4.7 step 1.2 says "If the result of the previous step was not
a valid key path, then..." - presumable this should read "... was not a
valid key, then..."
Received on Wednesday, 11 April 2012 23:48:06 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:51 GMT