[whatwg] Comments on updated SQL API
shess at google.com
Wed Oct 17 14:18:44 PDT 2007
On 10/17/07, Maciej Stachowiak <mjs at apple.com> wrote:
> On Oct 17, 2007, at 1:14 PM, Scott Hess wrote:
> > I think my concern is in two related bits:
> > A) As things currently stand, the developer simply can't roll their
> > own transaction structure. Passing BEGIN, COMMIT, or ROLLBACK to
> > executeSql() doesn't do anything sensible. It's possible you could
> > somehow do something using temporary tables, but that's going to be
> > really dependent on your underlying SQL implementation's capabilities.
> Would replacing closeTransaction() with commitTransaction() and
> rollbackTransaction() address this?
It might, but I'd still wonder how far the spec wants to go down the
road of replicating/enforcing the SQL transaction model. I think
having convenience functions is helpful to developers, it's the notion
of having _only_ the convenience functions which concerns me. The
more the API adds things like implicit transactions and
commit/rollback functions, the more tightly tied it will be to a
specific SQL implementation's semantics.
A thought experiment we've used on the Gears team is to ask whether
something can be composed from more basic components entirely in
executeRawSql(), which does not have any transaction implications at
all. The spec's executeSql() could clearly be implemented as a
wrapper around executeRawSql(), as could the current
closeTransaction() and the above commitTransaction() and
rollbackTransaction(). executeRawSql() also allows the developer to
merrily shoot themselves in the foot, of course.
[I think where I'm going here might be "make easy things easy and hard
More information about the whatwg