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
