On Thu, May 12, 2011 at 10:57 AM, Federico Di Gregorio
<federico.digregorio@dndg.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