Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model

What's the current thinking in terms of events that we're firing?  I
remember we talked about this a bit, but I don't remember the conclusion and
I can't find it captured anywhere.

Here's a brain dump of the requirements as I remember them:
* Everything should have a source attribute.
* Everything done in the context of a transaction should have a transaction
attribute.  (Probably even errors, which I believe is not the current case.)
* Only success events should have a result.
* Only error events should have a code and a message....or should they just
have an error attribute which holds an IDBDatabaseError object?  (If it's
the former, then do we even need an interface for IDBDatabaseError to be
* IIRC, Jonas suggested at some point that maybe there should be additional
attributes beyond just the source and/or objects should link to their
parents.  (The latter probably makes the most sense, right?  If so, I'll bug

Is there anything I'm missing?

As far as I can tell, this means we need 5 events: an IDBEvent (with source)
and then error with transaction, error without, success with, and success
without.  That seems kind of ugly though.

Another possibility is that we could put a transaction attribute on IDBEvent
that's null when there's no transaction.  And then error and success would
have their own subclasses.  To me, this sounds best.



On Fri, Nov 19, 2010 at 3:44 AM, <> wrote:

>           Summary: [IndexedDB] Overhaul of the event model
>           Product: WebAppsWG
>           Version: unspecified
>          Platform: PC
>        OS/Version: All
>            Status: NEW
>          Severity: normal
>          Priority: P2
>         Component: Indexed Database API
>        AssignedTo:
>        ReportedBy:
>         QAContact:
>                CC:,
> 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.
> --
> Configure bugmail:
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

Received on Wednesday, 26 January 2011 19:48:39 UTC