Re: IndexedDB: ambiguity around IDBTransaction.error

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

On Tue, May 29, 2012 at 2:31 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Fri, May 25, 2012 at 1:16 PM, Alec Flett <alecflett@google.com> wrote:
> > I have found what feels like an ambiguity in the spec around
> > IDBTransaction..error and when it is available.
> >
> > In particular, 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.
> >
> > Thoughts?
>
> We have the 'finished' flag already, which I think is what we should
> use here. Unfortunately it's somewhat ambigious when a transaction
> becomes finished.
>
> Would you mind filing a bug on this?
>
> / Jonas
>