Re: Transaction control overhauling
От | Daniele Varrazzo |
---|---|
Тема | Re: Transaction control overhauling |
Дата | |
Msg-id | BANLkTin4rYi4LXVwFr+J9nC=+yov5Ch3dQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Transaction control overhauling (Federico Di Gregorio <federico.digregorio@dndg.it>) |
Ответы |
Re: Transaction control overhauling
Re: Transaction control overhauling |
Список | psycopg |
On Thu, May 12, 2011 at 1:13 PM, Federico Di Gregorio <federico.digregorio@dndg.it> wrote: > On 12/05/11 13:57, Magnus Hagander wrote: >>> II. add a method conn.set_transaction(isolation_level=None, >>> > read_only=None, deferrable=None) allowing to change one or more of the >>> > transaction settings. Calling the method would terminate the current >>> > transaction and put the new settings in place. Note that there are >>> > several ways for implementing this: >> Ugh. Big -1 on the "terminate current transaction". First of all, I >> *assume* you mean ROLLBACK and not COMMIT. But even so, I think it's a >> much better idea to raise a local exception when trying to change it >> while inside a transaction. >> > > That makes sense. Currently psycopg keeps track of the current > transaction level to be able to decide if to terminare the transaction > (with a ROLLBACK) or not. But that's less than optimal because the > result of set_transaction_isolation() depends both on internal state and > issued queries. Much much better to just raise an exception if inside a > transaction. I've implemented what discussed in this thread. Documentation explaining the new features is available in the docs online: http://initd.org/psycopg/docs/connection.html#connection.set_transaction The code is merged into my devel branch. Shall we resume the old tradition of adding features in "3rd digit releases" and have the library released as 2.4.2? Backward compatibility should be entirely preserved. Before releasing though I want to try to fix two issues: the multithread problem reported a few days ago (ticket #55) and possibly try to make life easier into virtualenv: even if the setup.py has been patched to avoid building mx support when the library can't be imported (but the includes are there), there is still some struggling about the matter [1] [2]. I think mx support should be optional even if built: at import time, if mx.DateTime is not found, psycopg should simply avoid registering mx adapters/typecasters and keep going on with stdlib's datetime objects. -- Daniele [1] https://github.com/dvarrazzo/psycopg/commit/af424821b70299704449337904d3ab7fb1b40751 [2] https://twitter.com/#!/mike360/statuses/75295024346177537
В списке psycopg по дате отправления: