16653 2012-04-06 18:41:31 +0000 IndexedDB: Define overloads for IDBDatabase.transaction() 2013-04-02 17:43:42 +0000 1 1 1 Unclassified WebAppsWG Indexed Database API unspecified All All RESOLVED FIXED P2 normal --- 1 jsbell jsbell bzbarsky jonas mcginnis900 mike odinho public-webapps robin public-webapps-bugzilla oldest_to_newest 66485 0 jsbell 2012-04-06 18:41:31 +0000 Currently the IDL is: IDBTransaction transaction (any storeNames, optional DOMString mode); There was discussion on the list about removing "any" and using overloads to define the binding behavior here, e.g.: IDBTransaction transaction (DOMString storeName, optional DOMString mode); IDBTransaction transaction (sequence<DOMString> storeNames, optional DOMString mode); IDBTransaction transaction (DOMStringList storeNames, optional DOMString mode); Not sure if we want sequence<DOMString> or DOMString[] (I think the former is the new hotness); also, not sure if DOMStringList can be defined to "coerce" to sequence<DOMString> to reduce the use of that type. 66490 1 jonas 2012-04-06 22:55:06 +0000 I don't think we can do this until ReSpec is changed to support it. Please let me know if I'm wrong though. I *think* the proper WebIDL syntax would be enum transactionMode { "readonly, "readwrite" }; IDBTransaction transaction ((DOMString or sequence<DOMString>) storeName, optional transactionMode mode); 67249 2 jsbell 2012-05-02 19:00:42 +0000 More broadly, methods that are currently spec'd to take "any" arguments that could be distinguished by WebIDL overloads should be, as this eliminates the need for this spec to deal with conversions (e.g. is passing a JS number to a function that takes a DOMString allowed or a TypeError?) This does NOT apply to arguments which are keys (which is covered clearly in the spec) or values (ditto, via HTML5 structured clone algorithm) That leaves: IDBDatabase.transaction(any storeNames, ...) IDBObjectStore.createIndex(..., any keyPath, ...) (plus IDB*Sync variants) As an example where spec ambiguity could exist, the behavior of JS and undefined and null values for is well covered by the WebIDL spec in the case of db.createObjectStore(name, {keyPath: VALUE_IN_QUESTION}) but not in the case of store.createIndex(name, VALUE_IN_QUESTION). Ensuring that the interpretation the keyPath value in both methods is dictated by WebIDL seems highly desirable. 67265 3 jonas 2012-05-02 21:37:18 +0000 Robin, any plans to get ReSpec fixed to support these types of things? 83875 4 jsbell 2013-03-01 19:05:11 +0000 This should be resolved in: https://dvcs.w3.org/hg/IndexedDB/rev/b6d2f7b5a5a0 Since I filed this, I'd appreciate it if someone else could verify that the changes make sense. 85429 5 bzbarsky 2013-04-02 17:43:42 +0000 For what it's worth, the changes make sense to me as a binding implementor. I can't speak for whether they make sense for indexeddb per se...