Message216738
| 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:46 | aymeric.augustin | set | recipients:
+ 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:46 | aymeric.augustin | set | messageid: <1397767426.6.0.13137648705.issue10740@psf.upfronthosting.co.za> |
| 2014年04月17日 20:43:46 | aymeric.augustin | link | issue10740 messages |
| 2014年04月17日 20:43:46 | aymeric.augustin | create |
|