[whatwg] SQL API complex for simple cases

[Scott Hess]

On Oct 31, 2007 5:21 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Wed, 31 Oct 2007, Timothy Hatcher wrote:
> > How is that wrong? If the first executeSql fails the error callback (if
> > any) will fire, not the normal callback.
> >
> >   db.executeSql('CREATE TABLE ...', [], function(...) {
> >     db.executeSql('INSERT INTO ...', []);
> >   });
> >
> > If the CREATE TABLE fails, the insert will never happen. If the INSERT
> > fails, you don't really want the table to be rolled out. If you did,
> > then you want a transaction. There are clearly times where you don't
> > always want a transaction, but want to chain statements.
>
> What if another page dropped the table between the CREATE and the INSERT?

What if you went to insert into a table that someone else had dropped
in any case?

I think Timothy's point is that for the simple case where you really
_do_ intend to execute an ordered sequence of SQL statements which
aren't in a transaction, the new API is a bit more convoluted.  I
think his point is sound, but I'm not certain how important that
use-case is.  Realistically, you're usually either executing a
singleton statement, or you're executing a set of logically connected
statements which want to be in a single transaction.

I think that there might be some value to having better support for a
singleton statement, though.  Right now, your result-set handling is
inside the implicit transaction.  With a singleton executeSql() API
off of Database, your resultset handling could be pushed out of the
transaction, which would be good.

-scott