[DB-SIG] Last round for DB API 1.1

[Tod Olson]

>>>>> "AD" == Andy Dustman <adustman@comstar.net> writes:

AD> On Wed, 17 Mar 1999, M.-A. Lemburg wrote:
>> What to do about Andy Dustmans proposal to have .rollback()
>> raise an exception in case transactions are not supported by
>> the database ?

>> IMHO, we should leave the situation as it is: some DBs do not
>> support transactions (e.g. MySQL), some do but you can turn
>> transactions off [...]

>> If the API were to raise an exception in case tranactions are not
>> supported, the underlying interface would have to query the current
>> state prior to every .rollback() [...]

AD> Well, look at it this way. If you were using a database that
AD> supported transactions, and it was operating in a transactional
AD> mode, you'd expect an exception if, for some reason, the rollback
AD> couldn't be completed. [...The] simplest way to do this is to
AD> simply not implement the rollback method if no support is
AD> available, which will raise an AttributeError.

In a similar vein, if I were porting, say, a Sybase application to
MySQL, I would want some indication that a rollback did/could/would
not happen.  That is, if the DBAPI is to be thought of as an aid to
portability, I want some clue when a DB module has unexpected
behavior.  "def rollback(): pass" seems the worst possible case.

I think Andy's notion is pretty sound, and probably generalizable.

My 2 cents.  (Oh, for a cent sign!)

Tod A. Olson                        "How do you know I'm mad?" said Alice.
ta-olson@uchicago.edu               "If you weren't mad, you wouldn't have
The University of Chicago Library    come here," said the Cat.