- From: Dumitru Daniliuc <dumi@chromium.org>
- Date: Mon, 1 Feb 2010 16:58:14 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-webapps <public-webapps@w3.org>
- Message-ID: <e753f47f1002011658t99014ecja26586916b218d0f@mail.gmail.com>
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 UTC