[whatwg] Question on handling of failed statements in database API

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'