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

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

From: Israel Hilerio <israelh@microsoft.com>
Date: Mon, 13 Jun 2011 20:00:43 +0000
To: Cameron McCormack <cam@mcc.id.au>, timeless <timeless@gmail.com>
CC: Jonas Sicking <jonas@sicking.cc>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3D14C28B@TK5EX14MBXC115.redmond.corp.microsoft.com>
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/


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:

createObjectStore("car", { keyPath: "id", autoIncrement: true, other: value, required: ["keyPath", "autoIncrement"]});

createObjectStore("car", { keyPath: "id", other: value, required: ["keyPath"]});

createObjectStore("car", { autoIncrement: true, other: value, required: ["autoIncrement"]});

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?

Received on Monday, 13 June 2011 20:01:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:20 UTC