[whatwg] SQL API complex for simple cases

[Brady Eidson]

On Oct 31, 2007, at 4:03 PM, Ian Hickson wrote:

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

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.

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.

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

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

Thanks,
~Brady