[DB-SIG] annotated 1.1 spec / feedback

M.-A. Lemburg mal@lemburg.com
Tue, 16 Mar 1999 09:58:15 +0100

Andy Dustman wrote:
> The only other thing I worry about somewhat is the handling of
> transactions. On a db without transactions (MySQL), commit() can simply do
> nothing. rollback(), however, is another matter. I tend to think that
> rollback() on a database without transactions should raise some kind of
> exception. Perhaps it simply should not be defined so that an
> AttributeError is raised, so the application can at least try to take some
> corrective action.
> Another possibility is some kind of capabilities object which the
> application can use to determine what features are available. One obvious
> capability is the presence or absence of transactions. Another might be
> the type of parameter substitution used by the query language. I'm not
> really sure how useful this would be. Every database has it's own quirks,
> it seems, and it's probably not possible to work around all of them.
> However, at least knowing that transactions aren't available might at
> least let some alternate code work around this.

We could add a module global 'transactionlevel' to make this
information available with values:

	0	- database does not support transactions
	non-0	- bit field containing database specific information
		  about how transactions are implemented

ODBC has an API to query database/driver capabilities called
SQLGetInfo which provides the above under the id
SQL_DEFAULT_TXN_ISOLATION. You may want to look at the ODBC
docs at:
To get an impression of what the above bit field could look

As for .rollback() I'm not sure whether raising an exception
would help much: transactions are a very basic concept and
a work-around is likely not going to be possible by writing
a simple try-except handler.

Marc-Andre Lemburg                               Y2000: 290 days left
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :