[whatwg] SQL API complex for simple cases

[Ian Hickson]

On Wed, 31 Oct 2007, 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.

The reasoning behind the current state of the spec is that if we provide a 
way to not have transactions, authors will mis-use the API and end up 
writing scripts that cannot handle multiple windows using the same 
database. The current plan is to look into introducing a non-transactioned 
API alternative in v2.


> 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)", []) });

It's not really all that bad, IMHO.


> 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.

The problem with returning the object is that then we have no scope to 
know when the transaction should close.


> 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.

Indeed, the API is intended for JavaScript. I recommend providing APIs 
optimised for other languages when it comes to UA-specific code.


On Wed, 31 Oct 2007, Brady Eidson wrote:
> 
> 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.

What if there's a problem with opening the transaction itself? You don't 
want to run all the code for preparing the statement only to find you 
didn't have a chance for the statement to run in the first place.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'