[Bug 17236] New: Ambiguity in IDBTransaction.error around 'done' state

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17236

           Summary: Ambiguity in IDBTransaction.error around 'done' state
           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: alecflett@chromium.org
         QAContact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org


The spec says:
When the done flag is true, getting this property must return the error of the
request that caused the transaction to be aborted. [...] When the done flag is
false, getting this property must throw a DOMException of type
InvalidStateError.

The ambiguity here is that the 'done flag' is technically something that
resides on the request, not the transaction. After the transaction itself is
complete, the 'error' attribute should be the error that caused the transaction
to abort, if any. So the question is, which 'done' flag does this correspond to
- the done flag on the current request, the done flag on the request that
caused the abort, or some other 'done' state about the transaction itself.

An example:

transaction = ...
transaction.objectStores("foo").put(badValue).onerror = function(event) {
  // can I access transaction.error here?

  // the request has its own error though.
  requestError = event.target.error;

  transaction.objectStores("foo").put(goodValue).onsuccess =function(event) {
  // can I access transaction.error here? If so, is it requestError, or is it
null?
  }
}

transaction.objectStores("foo").put(goodValue).onsuccess = 

As a consumer of this interface, I'd expect the transaction's error property to
be set early - i.e. available as soon as the error handler fires, above, and
then I'd expect it to remain unchanged for the duration of the rest of the
transaction. But I can see arguments against that. For instance, what happens
if preventDefault() is called? we need to avoid setting the error in that
case.. I think. So that would argue for some kind of 'done' flag / state for
the transaction itself.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 29 May 2012 16:12:05 UTC