W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2007

[whatwg] SQL API and Transactions

From: Brady Eidson <beidson@apple.com>
Date: Thu, 25 Oct 2007 20:33:21 -0700
Message-ID: <1F845EEB-3FFD-4C6F-81C0-54BF428503FE@apple.com>
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
Received on Thursday, 25 October 2007 20:33:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:37 UTC