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

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 UTC