[whatwg] SQL API complex for simple cases

[Ian Hickson]

On Wed, 31 Oct 2007, Brady Eidson wrote:
> 
> I don't know that the goal is to adopt a "non-transactioned" API, but 
> rather to present the transactioned API in a manner that is also easy to 
> use for "fire off one sql query and forget it" purposes.

The fear is that people would do:

   db.executeSql('...', [], function(...) {
     db.executeSql('...', []); // depends on the first call
   });

...without a transaction.


> database.transaction().executeSql(...) is both "transactioned," fitting 
> into the current API, and "fire it and forget it," which is very easy 
> for simple developer use.

Sure, you can do that now (well, using callbacks instead of chaining).


> > > 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.
> 
> Currently, the actual transaction to the database is opened in 
> transaction steps 1 and 2.
> 
> If we adopt this model, we'd have a SQLTransaction object, but the 
> transaction steps themselves won't have started.  The first call to 
> executeSql() could "set the transaction into motion", as it were - 
> starting with steps 1 and 2 where the transaction is opened.
> 
> Adopting this model is quite compatible with the current transaction 
> steps with only small modifications, imho.

   var transaction = db.transaction();
   transaction.executeSql(...);
   transaction.executeSql(...);

How do you know when the transaction is ended? You have no scoping.


> > 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.
> 
> While the spec *does* currently enforce preparing the statement at the 
> time of calling executeSql() just to mark the statement bogus, "marking 
> the statement bogus" is only a flag that takes effect later during the 
> transaction effects.
> 
> Therefore, why is it so necessary to prepare the statement before the 
> transaction is opened?  Why don't we parse and validate the statement in 
> the transaction steps themselves?
>
> If we adopted both of these models (Tims idea and allowing the statement 
> to be parsed in the transaction steps) and there was a problem with 
> opening the transaction itself, you'd get the 
> SQLTransactionErrorCallback and the statement would never even be 
> touched at all.

I'm talking about:

   var transaction = db.transaction(errorCallback);
   // the transaction has failed at this point
   // but we have no way to stop the next few lines from running:
   ...do lots of work to get the data to put into the transaction...
   transaction.executeSql('...', [expensiveData], ...);

vs:

   db.transaction(function (transaction) {
     // this never gets called, since the transaction failed
     ...do lots of work to get the data to put into the transaction...
     transaction.executeSql('...', [expensiveData], ...);
   }, errorCallback);


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