Re: autocommit and Django - Mailing list psycopg

From Karsten Hilbert
Subject Re: autocommit and Django
Date
Msg-id 20110614095917.GL2617@hermes.hilbert.loc
Whole thread Raw
In response to autocommit and Django  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
List psycopg
On Tue, Jun 14, 2011 at 10:42:15AM +0100, Daniele Varrazzo wrote:

> the connection.autocommit feature has created the problem shown here:
>
> https://code.djangoproject.com/ticket/16250
>
> I've taken a look and they have a set_autocommit method
> <https://code.djangoproject.com/browser/django/trunk/django/db/backends/creation.py#L347>
> implemented in a painful way: instead of being driver-specific they
> just invoke some random method on the connection, and the thing is
> compounds with the fact they *don't even know* there is a transaction
> somehow already open. As per discussion
> <http://archives.postgresql.org/psycopg/2011-05/msg00033.php>,
> psycopg's set_session gives an error if invoked in a transaction.
>
> Now, I would love to argue that Django's set_autocommit is written
> with the wrong anatomical part, the bug is theirs and it's all their
> problem. However, knowing the painful process they use to fix a bug I
> wouldn't be surprised it would take months (see how they handled the
> idle in transaction mess) and this would only be a problem for django,
> postgres and psycopg users, as 2.4.2 is the version installed by
> default by easy_install and friends. So I'm positive to change the
> semantics of set_session/autocommit and issue an implicit rollback if
> in transaction instead of raising an exception, as set_isolation_level
> does.

IIRC it was argued by a PG developer that .autocommit = True
should *not* issue an implicit rollback. If that's so:
Please don't make psycopg2 do the "wrong" thing so others
can "fix" their problems more easily ("fix": because they
wouldn't really fix it if psycopg2 allowed the "wrong" thing
to happen).

Instead, add a state variable somewhere:

    .changing_autocommit_causes_transaction_rollback

defaulting to False (the current, "correct" behaviour) which
Django can set to True if the insist on keeping to do the
"wrong" thing.

I am aware that this introduces some penalty even for other,
well-behaved code because setting autocommit will now
require checking the state of said variable.

Or else have another argument to .set_transaction():

    def set_transaction(autocommit=True/False/None, autocommit_implicit_rollback=False/True):

where autocommit_implicit_rollback defaults to False.

Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

psycopg by date:

Previous
From: Daniele Varrazzo
Date:
Subject: autocommit and Django
Next
From: Federico Di Gregorio
Date:
Subject: Re: autocommit and Django