- From: Dumitru Daniliuc <dumi@chromium.org>
- Date: Mon, 1 Feb 2010 16:29:51 -0800
- To: public-webapps <public-webapps@w3.org>, ian@hixie.ch
- Message-ID: <e753f47f1002011629p7074fd54g26bc6fbf85abfd30@mail.gmail.com>
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. Thanks, Dumi
Received on Tuesday, 2 February 2010 00:30:24 UTC