[whatwg] SQL API complex for simple cases
beidson at apple.com
Wed Oct 31 16:31:08 PDT 2007
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
>> transactions are handled now. However, I feel the current spec has
>> a turn towards a more complex model even for simple queries that
>> 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-
> 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
>> transaction callback. I think a better API would be:
>> SQLTransaction transaction();
>> SQLTransaction transaction(in SQLTransactionErrorCallback
>> Then you can call executeSql on the transaction object without
>> having to
>> less painful, but closures are usually expensive and add additional
> 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
>> it's just a dummy object that doesn't interfere with the database at
> What if there's a problem with opening the transaction itself? You
> 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.
More information about the whatwg