This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11348 - [IndexedDB] Overhaul of the event model
Summary: [IndexedDB] Overhaul of the event model
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: public-webapps-bugzilla
: 10302 10303 (view as bug list)
Depends on:
Reported: 2010-11-19 11:44 UTC by Jeremy Orlow
Modified: 2011-03-04 00:06 UTC (History)
4 users (show)

See Also:


Description Jeremy Orlow 2010-11-19 11:44:16 UTC
We talked about this for a while at TPAC.  Here's what I think we agreed upon at the time:

* All events should propagate from the IDBRequest to the IDBTransaction to the IDBDatabase.

* For error events, preventDefault must be called in order to avoid a transaction aborting.  (When you use onerror, you'd of course use false to do so.)

* If you throw within an event handler, the transaction will abort.  (Catch errors that you don't want to implicitly abort the transaction.)

* The success event will be non-bubbling (because having onsuccess on IDBTransaction and IDBDatabase would be confusing).

* The error event should be added to IDBTransaction and IDBDatabase and should bubble.

* createObjectStore should remain sync and simply abort the transaction on errors (which are pretty much constrained to quota and internal errors).

* createIndex is the same, except that indexes with a uniqueness constraint and existing data that doesn't satisfy it will present another (and more common) case that'll cause the transaction to abort.  The spec should have a red note that reminds people of this.
Comment 1 Jeremy Orlow 2010-11-22 15:08:55 UTC
*** Bug 10302 has been marked as a duplicate of this bug. ***
Comment 2 Jeremy Orlow 2010-12-10 12:22:05 UTC
*** Bug 10303 has been marked as a duplicate of this bug. ***
Comment 3 Jeremy Orlow 2011-01-28 21:19:37 UTC
More details from Jonas:

Actually, I was proposing something entirely different.

IDBRequest should look like this:

interface IDBRequest : EventTarget {
   attribute any result;
   attribute unsigned long errorCode;
   attribute DOMObject source;
   attribute IDBTransaction transaction;

   const unsigned short LOADING = 1;
   const unsigned short DONE = 2;
   readonly attribute unsigned short readyState;

            attribute Function       onsuccess;
            attribute Function       onerror;

"success" and "error" events are plain Event objects, i.e. no
indexedDB-specific properties.

The advantage of this is:
1. Request objects are actually useful as representing the request.
Consumers of a request can check what the readystate is and either get
the .result or attach a event listener as appropriate. (As things
stand now you can't really rely on .readyState. The only thing it
tells you is if you got to the request too late or not. If you risk
getting there too late you better rewrite your code)
2. Easier to implement a promises-style API on top of indexedDB.
3. More similar to for example XMLHttpRequest

The downside is:
1. Have to use a bigger syntax to get to the result. "event.result"
vs. "".
Comment 4 Jeremy Orlow 2011-02-15 01:31:11 UTC
Note that we also agreed that .result and .errorCode should raise before the readyState is DONE and should return undefined and 0 (respectively) when it is DONE but they're not applicable.
Comment 5 Jeremy Orlow 2011-02-24 22:07:59 UTC
Also, the way the spec is written, it seems as though we're saying events should be fired synchronously in some cases (like when a transaction is aborted).  We should fix that too.
Comment 6 Jonas Sicking (Not reading bugmail) 2011-03-04 00:06:32 UTC
This should now be FIXED!