On Oct 17, 2007, at 2:04 PM, Maciej Stachowiak wrote:
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.
Would replacing closeTransaction() with commitTransaction() and
rollbackTransaction() address this?
Additionally, if we replaced closeTransaction() with
commitTransaction() and rollbackTransaction(), that would fit in with
my idea of disallowing BEGIN/COMMIT/ROLLBACK in executeSql() as the
developer would still have manual control over the implicit transaction.
I'm very interested to hear everyone's thoughts on this.
~Brady
