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-05-12 10:36:42
Message-ID: BANLkTikiQp=fNDzcOz0Fg+s42HgimHkYbQ@mail.gmail.com (view raw or flat)
Thread:
Lists: psycopg
On Thu, May 12, 2011 at 10:57 AM, Federico Di Gregorio
<federico(dot)digregorio(at)dndg(dot)it> wrote:

>> To summarize: an autocommit parameter to set_transaction would be ok
>> enough as it's independent from the other ones. But it has the
>> shortcoming of giving no way to read the value back. We would have
>>
>>     conn.set_transaction(autocommit=True)
>>
>> which is not bad. but
>>
>>     conn.autocommit = True
>>
>> feels better and allows to read the value back. And it's used quite a
>> lot, more than going serialized I'd say.
>
> Agreed. I'd rather have both to have a single point to set transaction
> parameters AND autocommit and the attribute to recover the value.

Works for me.

> Or,
> maybe even better, we can have 4 attributes and the set_transaction() as
> a shortcut:
>
>        conn.autocommit
>        conn.transaction_isolation_level
>        conn.transaction_readonly
>        conn.transaction_deferrable
>        conn.set_transaction(isolation_level, autocommit, readonly, ...)

Wow, I thought you wanted to limit the dbapi extensions :)


> Note that you write read_only while I write readonly ... the

Funny, I wanted to write you "note that you use readonly but isolation_level" :D

> DBAPI has a long story of not using "_" for short, two word flags.

I see... no problem with it.


> DEFAULT is fine, but I don't think it will ever be used. :D

This is likely. However the important is to agree to set the
connection parameter by sending a command to the backend as opposite
of storing it in our state and repeating at every begin.


Looks like we are starting having a plan. I can start working on these
ideas in the next days, meanwhile if anybody else has comment, they
are welcome.


-- Daniele

In response to

Responses

psycopg by date

Next:From: Magnus HaganderDate: 2011-05-12 11:57:02
Subject: Re: Transaction control overhauling
Previous:From: Federico Di GregorioDate: 2011-05-12 09:57:40
Subject: Re: Transaction control overhauling

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