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

On Mon, Jun 13, 2011 at 1:00 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> On Tuesday, June 07, 2011 4:53 PM, Cameron McCormack wrote:> timeless:
>> > would having a field: "mandatory" which indicates which arguments (or
>> > feature names) must be supported by the implementation assuage your
>> > concern?
>> >
>> > createObjectStore("car", { mandatory: ["foreignKeys"], keyPath: "id",
>> > foreignKeys: [{keyPath: "brand", objectStore: "car-brands"}]);
>>
>> Certainly that would work for this case, and I kind of like it.
>>
>> I feel like there would be instances where you would need this fail-if-
>> property-not-specified behaviour and others where would don’t need it,
>> hence we needn’t require all unrecognised properties to cause the call to fail.
>> If we agree with that sentiment, then I think something like the above is the
>> way to go.  A question would be whether we want to have some IDL-level
>> support for JS objects specifying properties that need to be recognised for
>> the call to succeed, or whether it’s OK for individual specifications like
>> IndexedDB to define their own, like
>>
>>   dictionary ObjectStoreCreationOptions {
>>     sequence<DOMString> mandatory;
>>     DOMString keyPath;
>>     // ...
>>   };
>>
>> --
>> Cameron McCormack ≝ http://mcc.id.au/
>
> Timeless,
>
> We like your idea.  Following is my understanding of it.  Also, we prefer the term "required" instead of "mandatory", since "required" would be a way a dev could express what they expect the platform to support (i.e. what their implementation requires).
>
> Given the current IDB requirement to support "keyPath" and "autoIncrement" valid properties on optionalParameters, this is how I see devs using the proposed solution:
>
> Example1:
> createObjectStore("car", { keyPath: "id", autoIncrement: true, other: value, required: ["keyPath", "autoIncrement"]});
>
> Example2:
> createObjectStore("car", { keyPath: "id", other: value, required: ["keyPath"]});
>
> Example3:
> createObjectStore("car", { autoIncrement: true, other: value, required: ["autoIncrement"]});
>
> Example4:
> createObjectStore("car", { autoIncrement: true, other: value, required: ["other"]});
>
> In all of these examples, the additional property called "other" will not affect the execution of createObjectStore.  In addition, the system will be responsible for validating that the only two supported "required" fields would be "keyPath" and "autoIncrement".  Therefore, Example #4 will fail because "other" is not a supported required field.
>
> Is this what you were thinking?

For what it's worth, I've talked to various people here at mozilla
about this issue. Everyone else feels that while it's unfortunate that
users which expect a v2 API might silently get a different behavior on
a v1 API, it's a even bigger complexity to try to detect absence of
unrecognized properties.

So I'll relent and go with that opinion.

I think the required property is an interesting idea, but not
something that we need until there is a v2 which introduces properties
that a v1 implementation won't need.

So lets just use the dictionary syntax as defined by WebIDL with no
extra fancy stuff.

/ Jonas

Received on Monday, 13 June 2011 20:17:46 UTC