Author torsten
Recipients asvetlov, dholth, ghaering, r.david.murray, scott.urban, torsten
Date 2011-03-27.01:34:15
SpamBayes Score 5.68828e-12
Marked as misclassified No
Message-id <1301189658.65.0.456179788671.issue10740@psf.upfronthosting.co.za>
In-reply-to
Content
The attached patch is my take on this issue. I ran into the problem that during schema upgrades dropping a table was not rolled back. In another instance, renaming a table was not rolled back. This greatly increases the risk of data loss for our application.

Because I do not currently foresee which commands might need dropping out of a transaction and because of backwards compatibility woes, I added a new field to the sqlite3.Connection: operation_needs_transaction_callback

This function is called to decide if a running transaction should be implicitly committed (I'd consider this dangerous), if a transaction has to be started if not running (should normally always hold) or if the transaction state should be left alone.

For example, the "pragma foreign_keys = ..." is a no-op inside a transaction, therefore an implicit begin would be possibly harmful. In our application, we enable foreign keys when getting the connection out of the SQLAlchemy pool via a pool listener, which would be disabled if there is an implicit begin triggered.

The patch also adds a bunch of unit tests to cover the new behaviour.
History
Date User Action Args
2011-03-27 01:34:19torstensetrecipients: + torsten, ghaering, r.david.murray, asvetlov, dholth, scott.urban
2011-03-27 01:34:18torstensetmessageid: <1301189658.65.0.456179788671.issue10740@psf.upfronthosting.co.za>
2011-03-27 01:34:16torstenlinkissue10740 messages
2011-03-27 01:34:16torstencreate