[whatwg] Asynchronous database API feedback

[Brady Eidson]

On Dec 12, 2007, at 11:18 AM, Dimitri Glazkov wrote:

> Can you help me understand the problem you're pointing out? The
> difference between the idea outlined and the current spec is the
> absence of the transaction callback, but it basically (I think) has
> the equivalent net effect.

In the current spec, you know exactly when your transaction is "in  
flight" and available, because of the callback.  That's why  
executeSql() is only allowed from within a transaction or statement  
callback.
An app might decide to do something differently if the transaction  
callback doesn't come within a certain timeout, for example.
Additionally, the current spec reflects the reality that a transaction  
might not be allowed - getting the SQLTransactionErrorCallback right  
away.
Additionally, it is a common pattern to execute different sql  
statements based on the outcome of the previous statement or based on  
other program state when the time comes to decide what statement to  
execute next.

Your proposed model hides these realities to various degrees.  By  
allowing a queue of statements to build up then "pulling the trigger",  
there's no definitive point in time where the transaction actually  
begins executing, and a lot of work might be wasted queueing up a long  
list of statements before pulling that trigger, and other flexibility  
might be lost.

> db.createTransaction is just a mutable list of statements until the
> execute method is called. In fact, it could even probably be just a JS
> array.

Making it an array seems flawed - separate method calls is the right  
way to go, I think.

> tx.execute(..) immediately returns, then asynchronously (pardon the
> sketchiness):
> * opens transaction
> * calls optional errorCallback if fails
> * proceeds to execute statements in queue
> * calls optional successCallback upon success.

The current spec prevents you from queueing up statements until the  
transaction is guaranteed to be open already.  Speaking with direct  
implementation experience, I can attest that this is a Good Thing  
(tm).  See some of the reasons above.

> I don't see it as being too much different from the spec's transaction
> steps. In fact, I can easily see this written as a JS wrapper around
> the current spec.

If you think your model is easier, then I agree completely that it can  
be implemented as a JS wrapper around the current API.  But it hides  
details and options available in the current API as previously  
discussed.  It would be good for some developers (I'm assuming you ;)  
but not for others.

One thing your model would do over the current spec is make the API  
more complex.  I see more fuzzy interactions between the objects and  
more methods that don't make as much sense to me as the current spec.   
For example...

>>>> .. in which case single statements could be executed as:
>>>>
>>>> db.sql('select count(*) as count from chickadees', [],  
>>>> function(rs) {
>>>> console.log(rs.rows.count); }).execute();

Huh?  While I think the ability to simply execute a single statement  
without worrying about callbacks and transactions is valuable, the  
above syntax combined with the previously described relationship  
between db.sql() and tx.execute() makes my brain explode.  :)

I don't disagree that a simple way to execute a single statement is  
valuable, but I was thinking something more along the lines of using  
the current model as-is, and adding a method to database that has the  
first statement queued up in a transaction already.

~Brady