- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 25 Feb 2008 23:13:10 +0000 (UTC)
On Mon, 25 Feb 2008, Aaron Boodman wrote: > > Quick request for clarification on how to handle failed statements. > The spec says (4.11.6 - step 12): > > Call the error callback with a newly constructed SQLError object that > represents the last error to have occured in this transaction. If the > error callback returned false, and the last error wasn't itself a > failure when committing the transaction, then try to commit the > transaction. If that fails, or if the callback couldn't be called > (e.g. the method was called with only one argument), or if it didn't > return false, then rollback the transaction. Any still-pending > statements in the transaction are discarded. > > So let's say: > - a statement fails So we're in the "In case of error" steps under "4.11.6 Processing model", step 6. > - we call the statement error handler, and it does not return false So we jump to step 12. > - we call the transaction error handler, and it returns false So now we have checked, and the author wants the transaction committed anyway, so: > - we attempt to commit, and the commit fails > > It seems like at this point, the proposal says that we should just > silently fail. (That is, don't call the transaction failure callback > again). It seems like this loses information. The commit may fail for > some other reason that why the statement failed. True. > What do people think of changing the proposal to remove > SQLTransactionErrorCallback's return value. It seems like whatever you'd > want to do with it, you could do with SQLStatementErrorCallback. > Granted, you might have to have an error callback for every statement, > but I feel like ignoring failed statements is kinda an edge case. Ok, done. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 25 February 2008 15:13:10 UTC