Re: Transaction control overhauling

On 12/05/11 11:33, Daniele Varrazzo wrote:
> On Thu, May 12, 2011 at 9:01 AM, Federico Di Gregorio
[snip]
> So, total anarchy here :\. The autocommit attribute would have been my
> favourite, but psycopg uses more often methods than read/write
> attributes (probably there is none of them) so the autocommit() method

Yep, probably because they didn't existed when psycopg2 was started.

> would blend better. But now, thinking about that, there would be no
> natural way to read back the value, for which there is no PG parameter
> to SHOW... so the attribute solution seems really the best option
> (unless making a pair set_autocommit/autocommit... ugh).

There is no PG parameter because autocommit doesn't really exists. It is
a side effect of not issuing a BEGIN before other commands: every
command gets its own (implicit) transaction.

> 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. 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, ...)

> I would think that read_only would more used than deferrable, which
> looks a pretty specialized level. No problem anyway as I expect all
> the parameters after the first to be called as keyword, e.g. people
> may want to use:
>
>     conn.set_transaction(READ_COMMITTED)
>     conn.set_transaction(read_only=True)
>     conn.set_transaction(SERIALIZED, read_only=True, deferrable=False)
>
> and not
>
>     conn.set_transaction(SERIALIZED, None, False, True)

Agreed. Note that you write read_only while I write readonly ... the
DBAPI has a long story of not using "_" for short, two word flags.

>> Do we need the ability to pass "default"? When the user call
>> set_transaction() with missing or None parameters do we want to send
>> "default" or stay with the current value? I favor the latter, e.g.,
>
> Yes, me too: None would mean don't change, not reset to default, and
> setting the default would require a different symbol, such as
> set_transaction(read_only=DEFAULT). We don't strictly need it of
> course: people can still query the connection and later reset to the
> original value. I agree it's not the most likely use case though, we
> may also avoid this feature.

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

federico

--
Federico Di Gregorio                         federico.digregorio@dndg.it
Studio Associato Di Nunzio e Di Gregorio                  http://dndg.it
 To prepare such test data, I get into the meaniest, nastiest frame of
  mind that I can manage, and I write the cruelest code I can think of;
  then I turn around and I embed that in even nastier constructions
  that are almost obscene.                                  -- D.E.Knuth