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

Re: [indexedDB] OptionalParameter question on IDBDatabase.createObjectStore

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 31 May 2011 15:40:37 -0700
Message-ID: <BANLkTimbOXg_d8oD5dUC0koruam4ebRycg@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>, Israel Hilerio <israelh@microsoft.com>, public-webapps@w3.org
On Tue, May 31, 2011 at 3:09 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> 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.

It's certainly harder to implement, but it does IMHO result in a
better API for webpages to use which is more important.

> 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
>    }
>  }

Yes, that is one option. Another could be something like:

if (objectStore.spiffyNewIndexes) {
  objectStore.createIndex("test", { spiffy: true });
}
else {
  objectStore.createIndex("test", { keyPath: "foo" });
}

In any case it's better to throw than silently ignore unknown properties IMHO.

/ Jonas
Received on Tuesday, 31 May 2011 22:41:34 GMT

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