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

Re: [indexedDB] OptionalParameter question on IDBDatabase.createObjectStore

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 1 Jun 2011 10:09:07 +1200
To: Jonas Sicking <jonas@sicking.cc>
Cc: Israel Hilerio <israelh@microsoft.com>, public-webapps@w3.org
Message-ID: <20110531220907.GA31214@wok.mcc.id.au>
Jonas Sicking:
> At least in the indexedDB case we need to enumerate the object anyway
> since we want to throw if it contains any properties that we don't
> understand. This is for forwards compatible reasons.
> 
> Hence we automatically limit ourselves to enumerable properties, so
> toString wouldn't be a problem.

The way I’ve specified dictionaries, there is no way to know what other
properties might exist on the JS object.  If you defined

  dictionary ObjectStoreCreationOptions {
    DOMString keyPath = "";
    boolean autoIncrement = false;
  };

then the (IDL level) dictionary value will only ever have a keyPath and
an autoIncrement entry.

I could add a flag to the dictionary that indicates whether “unexpected”
properties were on the (language level) object, so that IndexedDB can
act upon it by throwing an exception.  I’m just not sure that this is a
common usage pattern of options objects in JS.  To me, the simplest use
of the properties on the options object would be:

  function createObjectStore(name, optionalParameters) {
    optionalParameters = optionalParameters || { };
    var keyPath = optionalParameters.keyPath || "";
    var autoIncrement = optionalParameters.autoIncrement;
    ...
  }

Doing:

  function createObjectStore(name, optionalParameters) {
    optionalParameters = optionalParameters || { };
    var keyPath = optionalParameters.keyPath || "";
    var autoIncrement = optionalParameters.autoIncrement;
    for (var key in optionalParameters) {
      if (key != "keyPath" && key != "autoIncrement") {
        throw ...;
      }
    }
    ...
  }

feels kind of unnecessary.  Are you thinking that authors will feature
test for new options by doing something like the following?

  try {
    createObjectStore("test", { newOption: 123 });
  } catch (e) {
    if (e.code == IDBDatabaseException.NON_TRANSIENT_ERR) {
      // fall back to something else that does use newOption
    }
  }

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 31 May 2011 22:09:40 GMT

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