On 14/06/11 11:42, 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.
>
> Thoughts?
Yes, it is wrong. set_isolation_level() was wrong from the start but we
had to keep it that way to avoid breaking compatibility. The discussion
you linked still holds so I won't go back to sending a magic ROLLBACK.
If we don't want to wait for the #@§%£$! person that wrote the Django
code to fix it we can just make .autocommit a real attribute and set the
session autocommit mode when it is assigned True/False.
--
Federico Di Gregorio federico.digregorio@dndg.it
Studio Associato Di Nunzio e Di Gregorio http://dndg.it
Ma nostro di chi? Cosa abbiamo in comune io e te? -- Md