Re: IndexedDB: ambiguity around IDBTransaction.error
On Fri, May 25, 2012 at 1:16 PM, Alec Flett alecfl...@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
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 jo...@sicking.cc wrote:
On Fri, May 25, 2012 at 1:16 PM, Alec Flett alecfl...@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
IndexedDB: ambiguity around IDBTransaction.error
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 http://www.w3.org/TR/IndexedDB/#dfn-request-done flag is
true, getting this property *must* return the error of the request that
caused the transaction http://www.w3.org/TR/IndexedDB/#dfn-transaction to
be aborted. [...] When the
donehttp://www.w3.org/TR/IndexedDB/#dfn-request-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?
Alec
