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
defined?)
* 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
it.)

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.

Thoughts?

J

On Fri, Nov 19, 2010 at 3:44 AM, <bugzilla@jessica.w3.org> wrote:

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=11348
>
>           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: dave.null@w3.org
>        ReportedBy: jorlow@chromium.org
>         QAContact: member-webapi-cvs@w3.org
>                CC: mike@w3.org, public-webapps@w3.org
>
>
> 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: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>
>