Re: autocommit and Django
От | Karsten Hilbert |
---|---|
Тема | Re: autocommit and Django |
Дата | |
Msg-id | 20110614095917.GL2617@hermes.hilbert.loc обсуждение исходный текст |
Ответ на | autocommit and Django (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Список | 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 по дате отправления: