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

On Tuesday, October 04, 2011 3:01 AM, Jonas Sicking 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 the "error" event on all still pending 
> requests in step 2. The reason is also available while firing the 
> "abort" event on the transaction itself.
> 
> / Jonas
 
Independent on how we handler error, we like this approach!  This is our interpretation of the impact it will have on the overall feature.
 
SCENARIO #1:
Whenever there is an error on a request, the error value associated with the request will be assigned to the transaction error value.
The error value in the transaction will be available on the IDBTransaction.onerror and IDBTransaction.onabort handlers.
 
SCENARIO #2:
Whenever there is an error associated with the transaction (e.g. QUOTA or TIMEOUT ), the error value associated with the failure (e.g. QUOTA or TIMEOUT) will be assigned to the transaction error value.  The error value in the transaction will be available on the IDBTransaction.onerror and IDBTransaction.onabort handlers.
 
SCENARIO #3:
A developer uses the IDBTransaction.abort() method to cancel the transaction.  No error will be assigned to the transaction error value. The error value will be 0 (or empty string/null) when the IDBTransaction.onabort handler is called.
 
SCENARIO #4 (to be complete):
Whenever there is an error on a request, the error value associated with the request will be assigned to the transaction error value. However, if the event.preventDefault() method is called on the request, the only handler that will be called will be IDBTransaction.onerror and the error value will be available in the transaction.  This implies that the value of the first transaction event error that is not cancelled or prevented from executing its default behavior will be value that will be contained by the error on the transaction when the IDBTransaction.onabort handler is called.  See example below:
 
request1 ==> fires onerror with event.target errorCode == DATA_ERR                                                       
//request1 will preventDefault on the error event
transaction ==> fires onerror with this.errorCode = event.target.errorCode == DATA_ERR

request2 ==> fires onerror with event.target errorCode == CONSTRAINT_ERR
//request2 will let the error continue on its default path 
transaction ==> fires onerror with this.errorCode = event.target.errorCode == CONSTRAINT_ERR     
//the error sent to the transaction onerror handler will be passed to the onabort error event

request3 ==> fires onerror with event.target.errorCode == ABORT_ERR
transaction ==> fires onerror with this.errorCode = event.target.errorCode == ABORT_ERR
transaction ==> fires onabort with this.errorCode =  event.target.errorCode == CONSTRAINT_ERR

SCENARIO #5 (to be complete): 
Whenever there is an error on a request, the error value associated with the request will be assigned to the transaction error value.
However, if the event. stopPropagation() method is called on the request, the only handler that will be called will be IDBTransaction.onabort and the error value will be available in the transaction.
 
Do you agree?
 
Israel

Received on Thursday, 6 October 2011 22:31:08 UTC