[whatwg] Comments on updated SQL API

[Scott Hess]

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
JavaScript.  Posit a version of the API which instead implements
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
things possible".]

-scott