This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author aymeric.augustin
Recipients Jeremy Banks, Mark.Bucciarelli, Ronny.Pfannschmidt, adamtj, asvetlov, aymeric.augustin, dholth, ghaering, monsanto, r.david.murray, scott.urban, torsten, tshepang, zzzeek
Date 2014-04-17.20:43:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1397767426.6.0.13137648705.issue10740@psf.upfronthosting.co.za>
In-reply-to
Content
That patch solves the problem, at the cost of introducing an unwieldy API, "operation_needs_transaction_callback".

I'm very skeptical of the other API, "in_transaction". Other database backends usually provide an "autocommit" attribute.

"autocommit" is the opposite of "in_transaction" for all practical purposes. There's only two situations where they may be equal:

- before the first query
- after an explicit commit

Then you aren't in a transaction and you aren't in autocommit. But in these cases, in practice, the question you want to ask is "is the next query going to create a transaction?" (and if not, I may want to create one.)

So the semantic of "connection.autocommit" is much more useful than the semantic of "connection.in_transaction".

While you're there, it would be cool to provide "connection.autocommit = True" as an API to enable autocommit, because "connection.isolation_level = None" isn't a good API at all -- it's very obscure and has nothing to do with isolation level whatsoever.
History
Date User Action Args
2014-04-17 20:43:46aymeric.augustinsetrecipients: + aymeric.augustin, ghaering, Jeremy Banks, r.david.murray, zzzeek, asvetlov, adamtj, dholth, torsten, monsanto, scott.urban, tshepang, Ronny.Pfannschmidt, Mark.Bucciarelli
2014-04-17 20:43:46aymeric.augustinsetmessageid: <1397767426.6.0.13137648705.issue10740@psf.upfronthosting.co.za>
2014-04-17 20:43:46aymeric.augustinlinkissue10740 messages
2014-04-17 20:43:46aymeric.augustincreate