RE: FW: [indexeddb] transaction commit failure

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 Monday, 22 August 2011 21:28:15 UTC