From: | Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> |
---|---|
To: | psycopg(at)postgresql(dot)org |
Subject: | Re: autocommit and Django |
Date: | 2011-06-14 09:59:17 |
Message-ID: | 20110614095917.GL2617@hermes.hilbert.loc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Federico Di Gregorio | 2011-06-14 10:02:26 | Re: autocommit and Django |
Previous Message | Daniele Varrazzo | 2011-06-14 09:42:15 | autocommit and Django |