- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 22 Aug 2011 17:26:43 -0700
- To: Eliot Graff <Eliot.Graff@microsoft.com>
- Cc: Israel Hilerio <israelh@microsoft.com>, "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>
We should also explicitly mention that canceling the event (by calling preventDefault) does *not* prevent the transaction from being aborted. / Jonas On Mon, Aug 22, 2011 at 2:27 PM, Eliot Graff <Eliot.Graff@microsoft.com> wrote: > I added a step 3 to 4.3 Steps for committing a transaction: > > 3. If an error occurs while committing the transaction, fire an error event with type set to UNKNOWN_ERROR, and then follow the steps for aborting a transaction. > > Thanks, > > Eliot > >> -----Original Message----- >> From: public-webapps-request@w3.org [mailto:public-webapps- >> request@w3.org] On Behalf Of Jonas Sicking >> Sent: Wednesday, August 17, 2011 4:56 PM >> To: Israel Hilerio >> Cc: public-webapps@w3.org; Tom Bolds; Adam Herchenroether; Victor Ngo; >> me@shawnwilsher.com >> Subject: Re: FW: [indexeddb] transaction commit failure >> >> On Wed, Aug 17, 2011 at 3:08 PM, Israel Hilerio <israelh@microsoft.com> >> wrote: >> > 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. >> >> Ok, that works for me. >> >> / Jonas >> > >
Received on Tuesday, 23 August 2011 00:27:49 UTC