[DB-SIG] Last round for DB API 1.1
Tod Olson <email@example.com>
Wed, 17 Mar 1999 14:33:27 -0600
>>>>> "AD" == Andy Dustman <firstname.lastname@example.org> 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.
email@example.com "If you weren't mad, you wouldn't have
The University of Chicago Library come here," said the Cat.