Re: [IndexedDB] Reason for aborting transactions

On Tue, Feb 8, 2011 at 11:37 AM, ben turner <bent.mozilla@gmail.com> wrote:

> > I think that's what Ben was suggesting.
>
> Yes. We already have ABORT_ERR, no reason we can't subdivide that
> since it's being overloaded. In fact I think it makes perfect sense.
>

That part of the spec seems completely broken (there are no "steps to abort
a transaction" in the spec and it's not clear how ABORT_ERR would be plugged
in).  Either way, ABORT_ERR should probably be removed.


> > Add the following to IDBTransaction:
>
> I'm really not a fan of making IDBTransaction more complicated. We
> already have a generic "tell me when something goes wrong, and why"
> mechanism via errorCode


errorCode is something on the IDBRequest object these days, right?  Clearly
we can't use that when we're in an abort handler to figure out why we were
aborted.  I'm pretty sure we need to add a code (no matter what we name it
and where the code enums live) to IDBtransaction.


> and onError/onAbort. Why add another one? If
> the name is confusing we could rename it to exceptionCode perhaps?
>
> >   readonly attribute abortMessage;
>
> We dropped errorMessage already, let's not add abortMessage.
>

We did?  When and why?  I think the text based messages can be very useful
for debugging.  And they're there for exceptions.


> > And just set the message/code right before firing an abort event.
>
> And what happens when someone calls .abortCode before the transaction
> has finished? Or if the transaction succeeded?


What happens when you try to access the error code on IDBRequest today?
 (Serious question, I don't remember.)


> Or if the transaction
> failed for some other reason?


If it fails for any reason, it'll result in an abort.


> I think we'd probably want the same
> behavior as calling .errorCode, so again I think we should just roll
> the specific abort reasons into error codes and stick with our
> existing mechanism.
>

The existing mechanism doesn't fix the use case of being in an abort event
handler and wanting to know why you aborted.

J