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

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?

/ Jonas

Received on Tuesday, 4 October 2011 03:00:12 UTC