On Tue, Sep 29, 2009 at 02:56:41PM -0700, David E. Wheeler wrote: > On Sep 29, 2009, at 2:51 PM, Darren Duncan wrote: > >> Going the other way, in SQL, there is a single terse SQL statement for >> starting/ending transactions, and doing the thing with savepoints. So for >> aside from maybe some consistency with legacy DBI features, why should DBI >> objects have begin/commit/rollback or methods specific to start/end >> savepoints at all?
That's pretty much my current position. I'm open to persuasion but it would have to be good. >> Why doesn't the user just do it in SQL like they do >> everything else in SQL? Its not like DBI is abstracting away other SQL >> language details, so why should it do so with the transaction/savepoint >> managing SQL? Unless some DBMSs support transactions but not with SQL? So >> maybe changing nothing in DBI is actually the best approach concerning >> savepoints. > > We already have the example of DBI transaction support; savepoints are just > an extension of that. Well, as you said earlier David, "Transactions <> Savepoints." Commit and rollback are methods partly to support drivers that emulate transactions n some way, partly to ensure client and server state stay in sync, and partly to allow, at least in theory, the use of transaction managers. > And if different databases support different > syntaxes, it'd be nice to have that abstracted into drivers. > For example, MySQL has the RELEASE SAVEPOINT syntax, but it does not exist > in Oracle, where the releasing of savepoints is automatic. It's best to > have an abstract DBI interface for things like that, IMHO. I'd be interested if someone could do the research to list what databases support savepoints and what syntax they use for the main statements. Tim.
