Re: [indexeddb] Implicit Transaction Request associated with failed transactions

On Tue, Oct 4, 2011 at 3:01 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Oct 3, 2011 at 7:59 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> > On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio <israelh@microsoft.com>
> wrote:
> >> Based on previous conversations, it seems we've agreed that there are
> situations in which a transaction could failed independent of explicit
> requests (i.e. QUOTA_ERR, TIMEOUT_ERR).  We believe that this can be
> represented as an implicit request that is being triggered by a transaction.
>  We would like to add this concept to the spec.  The benefit of doing this
> is that it will allow developers to detect the error code associated with a
> direct transaction failure.  This is how we see the concept being used:
> >>
> >> trans.onerror = function (e) {
> >> //eventTarget is mapped to an implicit transaction that was created
> behind the scenes to track the transaction
> >>
> >>  if (e.eventTarget.errorCode === TIMEOUT_ERR) {
> >>    // you know the transaction error because of a timeout problem
> >>  }
> >>  else if (e.eventTarget.errorCode === TIMEOUT_ERR) {
> >>   // you know the transaction error because of a quota problem
> >>  }
> >> }
> >>
> >> Our assumption is that the error came not from an explicit request but
> from the transaction itself.  The way it is today, the e.eventTarget will
> not exists (will be undefined) because the error was not generated from an
> explicit request.  Today, eventTargets are only populated from explicit
> requests.
> >
> > Good catch!
> >
> > We had a long thread about this a while back with the subject
> > "[IndexedDB] Reason for aborting transactions". But it seems to have
> > fizzled with no real conclusion as to changing the spec. In part that
> > seems to have been my fault pushing back at exposing the reason for a
> > aborted transaction.
> >
> > I think I was wrong :-)
> >
> > I think I would prefer adding a .errorCode on IDBTransaction through
> > (or .errorName or .error or whatever we'll end up changing it to).
> > This seems more clear than creating a implicit request object. It'll
> > also make it easy to find the error if you're outside the error
> > handler. With the implicit request, you have no way of getting to the
> > request, and thus the error code, from code outside the error handler,
> > such from code that looks at the transaction after it has run.
> >
> > And the code above would work exactly as is!
> >
> > Let me know what you think?
>
> In detail, here is what I suggest:
>
> 1. Add a .errorCode (or .errorName/.error) property on
> IDBTransaction/IDBTransactionSync.
> 2. The property default to 0 (or empty string/null)
> 3. In the "Steps for aborting a transaction" add a new step between
> the current steps 1 and 2 which says something like "set the errorCode
> property of <var>transaction</var> to <var>code</var>".
>
> This way the reason for the abort is available (through the
> transaction) while firing he "error" event on all still pending
> requests in step 2. The reason is also available while firing the
> "abort" event on the transaction itself.
>
>
LGTM.

We had discussed how to notify the script that a transaction aborted due to
quota during the commit, after all the operations' success handlers had been
called; an errorCode on IDBTransaction is what we were leaning toward.

/ Jonas
>
>