[whatwg] Comments on updated SQL API

[Brady Eidson]

On Oct 17, 2007, at 1:14 PM, Scott Hess wrote:

> On 10/17/07, Maciej Stachowiak <mjs at apple.com> wrote:
>> I'm not sure what other reasons Scott sees for (2). I do think it
>> would aid authoring clarity to have the word "transaction" in the  
>> API,
>> even if the model of how they are managed is much the same as
>> currently (so you can't forget to close it) and even if a
>> transactionless API is not added.
>
> 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.
>
> B) Transactions are a meaningful concept in SQL, and we're entangling
> that concept with an implementation detail of how the API is
> implemented.
>
> I'm gradually getting to where I don't feel strongly about B.  If you
> don't want a transaction, you can have serial calls to executeSql().
> If you want serial calls that are dependent, you can call
> closeTransaction() before making the next executeSql().  I agree that
> the following might be more self-documenting:
>
>  db.transaction(function () {
>    db.executeSql(...);
>  });
>
> On A, I'm still nervous.

I'm really starting to fall in to your way of thinking on this:
A is what makes me nervous and I think it largely complicates both the  
implicit transaction and changeVersion() issues.

"A future version of this specification may define the exact SQL  
subset required in more detail" - perhaps this future version of the  
spec might also specifically disallow begin/commit/rollback in  
executeSql(), which would be okay if we make the built-in alternative  
clear.

~Brady