On Oct 17, 2007, at 1:14 PM, Scott Hess wrote:
On 10/17/07, Maciej Stachowiak <[EMAIL PROTECTED]> 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
