Skip site navigation (1) Skip section navigation (2)

Re: Transaction control overhauling

From: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
To: Federico Di Gregorio <federico(dot)digregorio(at)dndg(dot)it>
Cc: psycopg(at)postgresql(dot)org
Subject: Re: Transaction control overhauling
Date: 2011-06-03 10:35:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: psycopg
On Thu, May 12, 2011 at 1:13 PM, Federico Di Gregorio
<federico(dot)digregorio(at)dndg(dot)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:

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 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


In response to


psycopg by date

Next:From: Federico Di GregorioDate: 2011-06-03 13:18:17
Subject: Re: Transaction control overhauling
Previous:From: Daniele VarrazzoDate: 2011-06-03 07:54:21
Subject: Re: Installing via pip under Win7 + virtualenv + VC++2008

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group