Re: Transaction control overhauling - Mailing list psycopg

From Daniele Varrazzo
Subject Re: Transaction control overhauling
Date
Msg-id BANLkTin4rYi4LXVwFr+J9nC=+yov5Ch3dQ@mail.gmail.com
Whole thread Raw
In response to Re: Transaction control overhauling  (Federico Di Gregorio <federico.digregorio@dndg.it>)
Responses Re: Transaction control overhauling  (Federico Di Gregorio <federico.digregorio@dndg.it>)
Re: Transaction control overhauling  (Federico Di Gregorio <federico.digregorio@dndg.it>)
List 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 by date:

Previous
From: Daniele Varrazzo
Date:
Subject: Re: Installing via pip under Win7 + virtualenv + VC++2008
Next
From: Federico Di Gregorio
Date:
Subject: Re: Transaction control overhauling