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

Re: [indexeddb] Using WebIDL Dictionary in IDBObjectStore.createIndex for optionalParameters

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 7 Jun 2011 14:03:01 -0700
Message-ID: <BANLkTi=iUMxv02aaxP0kLb2iQy2k57FirA@mail.gmail.com>
To: Israel Hilerio <israelh@microsoft.com>
Cc: Cameron McCormack <cam@mcc.id.au>, "public-webapps@w3.org" <public-webapps@w3.org>
On Tue, Jun 7, 2011 at 11:26 AM, Israel Hilerio <israelh@microsoft.com> wrote:
> On Monday, June 06, 2011 3:25 PM, Cameron McCormack wrote:
>> Jonas Sicking:
>> > I don't know about other APIs. But it does seem very unfortunate to
>> > simply silently ignore unknown arguments to
>> > IDBDatabase.createObjectStore. Though then again, extra (and thus
>> > unknown) arguments are ignored to all other DOM calls.
>>
>> Right (not as defined in Web IDL at the moment, but will be soon).
>>
>> --
>> Cameron McCormack ≝ http://mcc.id.au/
>
> Jonas, could you elaborate why it is so important to reject/throw on the existence of any other properties on the optional parameters?  What are the side effects you believe we need to contain?
>
> Based on this thread, it seems like this behavior is inconsistent with what JS developers expect and how DOM APIs are designed.
>
> From our point of view, we don't believe getters and setters should be artificially restricted and we agree with Cameron on allowing our methods to take extra parameters and ignore them.

I've mentioned this many times already, but I'm concerned that
silently ignoring unknown properties means that people might expect
the properties to make the objectStore behave in a significantly
different way.

For example, say that we in version 2 of indexedDB add support for
foreign keys. So that you can say:

createObjectStore("car", { keyPath: "id", foreignKeys: [{keyPath:
"brand", objectStore: "car-brands"}]);

It seems bad that if a user thinking they are using a indexedDB
implementation which supports version 2 calls this function and expect
the foreignKey constraint enforced, but in reality they're calling it
on a v1 implementation which silently ignores it.

/ Jonas
Received on Tuesday, 7 June 2011 21:03:59 GMT

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