W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [IndexedDB] Reason for aborting transactions

From: ben turner <bent.mozilla@gmail.com>
Date: Tue, 8 Feb 2011 11:37:10 -0800
Message-ID: <AANLkTikL4KmqhfNErrTs+zViCYBra5cFL-ZT1Vg39F9e@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Jonas Sicking <jonas@sicking.cc>, Cameron McCormack <cam@mcc.id.au>, public-webapps WG <public-webapps@w3.org>
> 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.

> 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 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.

> 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? Or if the transaction
failed for some other reason? 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.

-Ben
Received on Tuesday, 8 February 2011 19:38:03 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT