[whatwg] SQL API complex for simple cases

[Brady Eidson]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20071031/c1b79035/attachment.htm>