- 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>
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 UTC