Admin Transaction Management Error

[holdenweb]

When using admin from the trunk [r8346] on Ubuntu I am getting occasional tracebacks like the following. I *appears* only to happen when one of the foreign key fields is changed, or at least I haven't been able to trigger the problem without changing one of them. I am only selecting values using the drop-downs populated from the related models.

Environment:

• Request Method: POST
• Request URL: ​http://test.holdenweb.com/admin/accounts/userprofile/14/
• Django Version: 1.0-alpha_2-SVN-8346
• Python Version: 2.4.3

Installed Applications:

['django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.admin',
 'pages',
 'grp',
 'contact',
 'registration',
 'accounts']

Installed Middleware:

('django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.middleware.doc.XViewMiddleware')

Traceback:

File "/home/holdenwe/django-trunk/django/core/handlers/base.py" in get_response
  86.                 response = callback(request, *callback_args, **callback_kwargs)
File "/home/holdenwe/django-trunk/django/contrib/admin/sites.py" in root
  172.                 return self.model_page(request, *url.split('/', 2))
File "/home/holdenwe/django-trunk/django/views/decorators/cache.py" in _wrapped_view_func
  44.         response = view_func(request, *args, **kwargs)
File "/home/holdenwe/django-trunk/django/contrib/admin/sites.py" in model_page
  189.         return admin_obj(request, rest_of_url)
File "/home/holdenwe/django-trunk/django/contrib/admin/options.py" in __call__
  275.             return self.change_view(request, unquote(url))
File "/home/holdenwe/django-trunk/django/db/transaction.py" in _commit_on_success
  251.             leave_transaction_management()
File "/home/holdenwe/django-trunk/django/db/transaction.py" in leave_transaction_management
  75.         raise TransactionManagementError("Transaction managed block ended with pending COMMIT/ROLLBACK")

Exception Type: TransactionManagementError at /admin/accounts/userprofile/14/
Exception Value: Transaction managed block ended with pending COMMIT/ROLLBACK

[holdenweb]

accounts/admin.py

[holdenweb]

accounts/models.py

[Malcolm Tredinnick]

(Fixed description to stop my eyes watering.)

Putting this on the 1.0 track because if it can ever be reliably repeated we should definitely fix it. That first part is going to be the trick, of course. Finding the right 'component' is a little tough, since we don't quite know where the problem lies. Making it admin for now, since that's the visible symptom at least.

[Manuel Saelices]

I tried to reproduce, with an application with these models and admin, but I cannot reproduce this error.

@holdenweb: ¿Can you give a complete demo app with fixtures inside? And there would be useful a list of steps to reproduce it.

[gkelly]

I am unable to reproduce using psycopg2 and postgresql 8.2.

holdenweb: what database engine are you using? Perhaps your entire settings.py would also be useful, with the complete demo app requested above too.

[Jacob]

I know Steve (aka holdenweb) well enough to know that this isn't to be dismissed lightly. However, without further information we can't reproduce this, so I'm going to mark worksforme until we get any more info.

[Jacob]

Right, we've got a working test case:

class Parent(models.Model):
    name = models.CharField(max_length=10)
    other_value = models.IntegerField(unique=True)

    def __unicode__(self):
        return u"XXX: %s" % self.name

class Child(Parent):
    father = models.OneToOneField(Parent, primary_key=True, to_field="other_value", parent_link=True)
    value = models.IntegerField()

    def __unicode__(self):
        return self.name

The bug looks to be related to the combination of parent_link and to_field; editing a Child in the admin will through transaction management errors intermittently.

[Malcolm Tredinnick]

We know what the problem is here (in django.db.models.base.Model.save()), but attempting to fix it now is just too risky. So this is going in as a "known issue" for 1.0. If the above example is the only way to trigger it, it's an extreme edge case and can be avoided by just not doing that for now.

[(none)]

Milestone post-1.0 deleted

[anonymous]

The problem can also hit when there's an error in the database schema. I just had a case where there was a broken constraint in the database and the fact that there's an Exception thrown in the finally block in _commit_on_success meant that instead of the real error from my database driver (postgresql_psycopg2) I saw the generic and not at all helpful error here. Sucks.

[anonymous]

If somebody came to this issue maybe: ​http://code.djangoproject.com/ticket/6623 will help something. I got problems in Django 1.3 / PostgresSQL, there is problem with commit_manually decorator - it hides real exception which in my case was MultipleObjectsFound thrown by .get() function...

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Aymeric Augustin <aymeric.augustin@…>]

In 14cddf51c5f001bb426ce7f7a83fdc52c8d8aee9:

Merged branch 'database-level-autocommit'.

Fixed #2227: atomic supports nesting.
Fixed #6623: commit_manually is deprecated and atomic doesn't suffer from this defect.
Fixed #8320: the problem wasn't identified, but the legacy transaction management is deprecated.
Fixed #10744: the problem wasn't identified, but the legacy transaction management is deprecated.
Fixed #10813: since autocommit is enabled, it isn't necessary to rollback after errors any more.
Fixed #13742: savepoints are now implemented for SQLite.
Fixed #13870: transaction management in long running processes isn't a problem any more, and it's documented.
Fixed #14970: while it digresses on transaction management, this ticket essentially asks for autocommit on PostgreSQL.
Fixed #15694: atomic supports nesting.
Fixed #17887: autocommit makes it impossible for a connection to stay "idle of transaction".