I originally had some objections to this, but think it might be okay.
My understanding with this design is that you would get this
SQLTransaction object back and it would just sit around, not doing
anything. When you first call executeSql on it, you kick off the
transaction steps as they already exist. Until you call executeSql(),
it's just a dummy object that doesn't interfere with the database at
all.
If the above understanding is how we change the spec, I'm all for it.
Thanks,
~Brady
On Oct 31, 2007, at 11:40 AM, Timothy Hatcher wrote:
I have finally looked over the new syntax and I'm starting to like
how transactions are handled now. However, I feel the current spec
has taken a turn towards a more complex model even for simple
queries that don't require transactions.
Compare:
db.executeSql("CREATE TABLE WebKitStickyNotes (id REAL UNIQUE, note
TEXT, timestamp REAL, left TEXT, top TEXT, zindex REAL)", []);
and
db.transaction(function(transacion) { transacion.executeSql("CREATE
TABLE WebKitStickyNotes (id REAL UNIQUE, note TEXT, timestamp REAL,
left TEXT, top TEXT, zindex REAL)", []) });
I think there needs to be an executeSql on the Database object
still. Using executeSql on the Database will just queue up
statements interleaved with the transactions.
The other problem I see that makes the current spec more complex is
the transaction callback. I think a better API would be:
SQLTransaction transaction();
SQLTransaction transaction(in SQLTransactionErrorCallback
errorCallback);
Then you can call executeSql on the transaction object without
having to wait for the callback. Sure, closures in JavaScript make
this somewhat less painful, but closures are usually expensive and
add additional complexity. Not to mention JavaScript is not the only
language that the DOM can be accessed from, for example in WebKit
using Objective-C where doing callbacks is a greater hassle.
— Timothy Hatcher
