RE: FW: [indexeddb] transaction commit failure

Added a note for that step:

Even if the event is cancelled (by a call to preventDefault), follow the steps for aborting a transaction.

> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: Monday, August 22, 2011 5:27 PM
> To: Eliot Graff
> Cc: Israel Hilerio; public-webapps@w3.org; Tom Bolds; Adam Herchenroether;
> Victor Ngo; me@shawnwilsher.com
> Subject: Re: FW: [indexeddb] transaction commit failure
> 
> 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 23:36:56 UTC