W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [WebSQLDatabase] Minor change to spec?

From: Dumitru Daniliuc <dumi@chromium.org>
Date: Mon, 1 Feb 2010 16:58:14 -0800
Message-ID: <e753f47f1002011658t99014ecja26586916b218d0f@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: public-webapps <public-webapps@w3.org>
Thanks for clarifying this, Ian.

Dumi


On Mon, Feb 1, 2010 at 4:53 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Mon, 1 Feb 2010, Dumitru Daniliuc wrote:
> >
> > In section 4.3.2, point 6, the "In case of error..." paragraph says:
> >
> > 2. If the error callback returns false, then move on to the next
> statement,
> > if any, or onto the next overall step otherwise.
> > 3. Otherwise, the error callback did not return false, or there was no
> error
> > callback. Jump to the last step in the overall steps.
> >
> > I'm proposing the following change (the wording could be different, of
> > course):
> >
> > 2. If the error callback returns false *and the transaction is not in an
> > unrecoverable state*, then move on to the next statement, if any, or onto
> > the next overall step otherwise.
> > 3. Otherwise, if the error callback did not return false, or there was no
> > error callback, *or the transaction is an unrecoverable state*, jump to
> the
> > last step in the overall steps.
> >
> > This request is motivated by
> http://www.sqlite.org/c3ref/get_autocommit.html:
> > "If certain kinds of errors occur on a statement within a multi-statement
> > transaction (errors including
> > SQLITE_FULL<http://www.sqlite.org/c3ref/c_abort.html>,
> > SQLITE_IOERR <http://www.sqlite.org/c3ref/c_abort.html>,
> > SQLITE_NOMEM<http://www.sqlite.org/c3ref/c_abort.html>,
> > SQLITE_BUSY <http://www.sqlite.org/c3ref/c_abort.html>, and
> > SQLITE_INTERRUPT<http://www.sqlite.org/c3ref/c_abort.html>)
> > then the transaction might be rolled back automatically." If such an
> error
> > occurs, we cannot move on to the next statement as currently requested by
> > the spec.
>
> These fall under the general "User agents may impose
> implementation-specific limits on otherwise unconstrained inputs, e.g. to
> prevent denial of service attacks, to guard against running out of memory,
> or to work around platform-specific limitations." rule, under which you
> can basically do whatever you need to do to handle unexpected errors.
>
> If I edit the spec again, I'll make this more clear.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
Received on Tuesday, 2 February 2010 00:58:44 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT