- From: Israel Hilerio <israelh@microsoft.com>
- Date: Wed, 17 Aug 2011 22:08:45 +0000
- To: "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>, Tom Bolds <thombo@microsoft.com>, Adam Herchenroether <aherchen@microsoft.com>, "Victor Ngo" <vicngo@microsoft.com>, "me@shawnwilsher.com" <me@shawnwilsher.com>
On Tuesday, August 16, 2011 8:08 AM, Jonas Sicking wrote: > On Monday, August 15, 2011, Shawn Wilsher <me@shawnwilsher.com> wrote: > > On 8/15/2011 3:31 PM, Israel Hilerio wrote: > >> > >> When the db is doing a commit after processing all records on the > >> transaction, if for some reason it fails, should we produce an error > >> event first and let the bubbling produce a transaction abort event or > >> should we only produce a transaction abort event. It seems that doing > >> the first approach would be more complete. > > > > I agree; the first approach seems better and I can't think of any reason why it would be difficult to implement. > > > > The catch is that calling `preventDefault` will not prevent the abort, which is (I think) different from how we handle other errors, right? > > Yeah, I'm tempted to say that that is enough of a reason for simply firing abort directly, but I could be convinced otherwise. > > / Jonas We would like to follow the first approach because it allows us to notify the developer that there was an error on the transaction and that is the reason the transaction was aborted. Israel
Received on Wednesday, 17 August 2011 22:09:15 UTC