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: Thu, 16 Jun 2011 20:16:27 +0000
To: Jonas Sicking <jonas@sicking.cc>
CC: Cameron McCormack <cam@mcc.id.au>, timeless <timeless@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3D14FDF6@TK5EX14MBXC115.redmond.corp.microsoft.com>
On Monday, June 13, 2011 1:17 PM, Jonas Sicking wrote:
> 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

Great!  I will work with Eliot to update the spec for the two APIs below, including their Synchronous counterparts, with:
-------
dictionary IDBDatabaseOptionalParameters {
   DOMString keyPath = null;
   boolean autoIncrement = false;
};

IDBDatabase:
IDBObjectStore createObjectStore (in DOMString name, in optional IDBDatabaseOptionalParameters optionalParameters) raises (IDBDatabaseException);

This will allow a developer to use this function in the following way:
var dbOptionalParams = { keyPath: "name" };
var name = “myObjectStore”;
var index = x.createObjectStore(name, dbOptionalParams);  //This will default the value of autoIncrement to false.

-------
dictionary IDBIndexOptionalParameters {
   boolean unique = false;
   boolean multientry = false;
};

IDBObjectStore:
IDBIndex   createIndex (in DOMString name, in DOMString keyPath, in optional IDBIndexOptionalParameters optionalParameters) raises (IDBDatabaseException);

This will allow a developer to use this function in the following way:
var indexOptionalParams = { unique: true };
var name = “myIndex”;
var keyPath = “name”;
var index = x. createIndex (name, keyPath, indexOptionalParams);  //This will default the value of multientry to false.

Israel
Received on Thursday, 16 June 2011 20:16:57 GMT

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