Re: Transaction control overhauling

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