[indexeddb] Implicit Transaction Request associated with failed transactions

• From: Israel Hilerio <israelh@microsoft.com>
• Date: Mon, 12 Sep 2011 21:53:20 +0000
• To: "public-webapps@w3.org" <public-webapps@w3.org>
• CC: Jim Wordelman <jaword@microsoft.com>, Tom Bolds <thombo@microsoft.com>, Cullen Sauls <cullens@microsoft.com>
• Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3D24F493@TK5EX14MBXC119.redmond.corp.microsoft.>

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.

Israel

Received on Monday, 12 September 2011 21:53:50 UTC