Bug 16653 - IndexedDB: Define overloads for IDBDatabase.transaction()
IndexedDB: Define overloads for IDBDatabase.transaction()
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API
unspecified
All All
: P2 normal
: ---
Assigned To: Joshua Bell
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-06 18:41 UTC by Joshua Bell
Modified: 2013-04-02 17:43 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Bell 2012-04-06 18:41:31 UTC
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.
Comment 1 Jonas Sicking 2012-04-06 22:55:06 UTC
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);
Comment 2 Joshua Bell 2012-05-02 19:00:42 UTC
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.
Comment 3 Jonas Sicking 2012-05-02 21:37:18 UTC
Robin, any plans to get ReSpec fixed to support these types of things?
Comment 4 Joshua Bell 2013-03-01 19:05:11 UTC
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.
Comment 5 Boris Zbarsky 2013-04-02 17:43:42 UTC
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...