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

[whatwg] SQL API complex for simple cases

From: Timothy Hatcher <timothy@apple.com>
Date: Wed, 31 Oct 2007 11:40:00 -0700
Message-ID: <3376D8FC-F9ED-428D-861D-95888819CF5F@apple.com>
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20071031/483b7d74/attachment.htm>
Received on Wednesday, 31 October 2007 11:40:00 UTC

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