[whatwg] Comments on updated SQL API

[Aaron Boodman]

On 10/17/07, Brady Eidson <beidson at apple.com> wrote:
> Additionally, if we replaced closeTransaction() with
> commitTransaction() and rollbackTransaction(), that would fit in with
> my idea of disallowing BEGIN/COMMIT/ROLLBACK in executeSql() as the
> developer would still have manual control over the implicit transaction.
>
> I'm very interested to hear everyone's thoughts on this.

Wow, this brings up something really scary that I never considered
about the current proposal:

In the current spec, the tx must stay open until callback returns,
right? That seems like the only reasonable way it could work. That's
too bad because since the callback is also overloaded as a way to get
the results of executeSql and do work, the callback might stay open
for a long time and do all sorts of other work, like starting
httprequests, starting new logical sql transactions, updating the UI,
etc.

It would be easy for developers to forget that the callback is also
used to keep the transaction alive and accidentally add all kinds of
other work to it.

commitTransaction() and rollbackTransaction() provide a way out of
this, but I would think the natural thing for developers to do would
be to be paranoid and *always* call these when done with their db
work.

This is the first thing that makes me question the current implicit
transaction API :-(. Maybe adding a executeSqlInTransaction() would be
smarter. You can then separate the two meanings of SQLCallback:

- getting results of a sql call
- linking sql calls together into transactions

- a