I still like the new API, but have a detail to nitpick on.

The fact that my most noteworthy complaint is this nitpick indicates how solid the API is, I think ;)

For major steps during processing of a transaction, if that step fails the SQLTransactionErrorCallback is invoked.

Additionally, for each statement processed within a transaction, success and failure in executing that statement both result in a callback - SQLStatementCallback and SQLStatementErrorCallback respectively.

With the above mechanisms, there is a lot of solid notification to the script about progress of a transaction. There seems to be a flaring hole, however.

Step 9 of the transaction steps stipulates that if the transaction fails to commit, the script will get an SQLTransactionErrorCallback indicating this failure. However, there is no final callback indicating *success* of the commit.

In the case of a general transaction used for a chain of executeSql calls, the script will have gotten a callback for each statement as it succeeds and therefore might assume the transaction will succeed. However, they don't know *when* is has succeeded. In the case of the transaction wrapped by a changeVersion() call, the script will definitely know when the changeVersion() fails, but will not know at what point in time the changeVersion() has finished and the data is all committed to disk.

I can see a script wanting to know when a transaction is actually 100% complete and committed before moving on to the next task. I just don't know how important it is, and wanted to bring this point up for discussion.

Thanks,
~Brady

Reply via email to