W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: FW: [indexeddb] transaction commit failure

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 17 Aug 2011 16:56:25 -0700
Message-ID: <CA+c2ei-9Rr3u4iRbfLyJnvxUzSVSnOD7OMeN046CDWnVUFz-+w@mail.gmail.com>
To: Israel Hilerio <israelh@microsoft.com>
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 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 Wednesday, 17 August 2011 23:57:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC