- From: Aaron Boodman <aa@google.com>
- Date: Sat, 22 Sep 2007 09:32:02 -0700
I agree with both Maciej's points, and want the second one more than he did. Additional comments: 4.12.3, step 3: I don't think you should implicitly join active transactions unless you're inside a callback from a previous executeSql call. Otherwise all code that wants to call executeSql needs to know about all other code using it and know to wait if it wants isolation. In the case where you're a top-level call to executeSql, you should start a new transaction. Some thought needs to be given to the type of transaction that should be started implicitly. Most database vendors support several. Here is the list of SQLite's: http://www.sqlite.org/lang_transaction.html I think the "immediate" type is the best all-around choice. 4.12.3, step 5: I think you need to fail with a specific error so that the caller knows this is the problem and can do the right thing I don't think closeTransaction() is necessary. For one thing, SQL already has "COMMIT" and "ROLLBACK". Secondly, if the developer wants each statement to be it's own transaction, he can make separate top-level calls. Other than that, lgtm. - a
Received on Saturday, 22 September 2007 09:32:02 UTC