Code

Opened 3 years ago

Last modified 13 months ago

#15568 new Bug

IntegrityError rises from test test_generic_key_deletion when it runs with the test test_generic_key_cross_database_protection for the INNODB

Reported by: rahul.priyadarshi@… Owned by: nobody
Component: contrib.contenttypes Version: 1.3-rc
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When i ran test cases of multiple_databases model of regressiontests then "test_generic_key_deletion" test case gave Error at the point where it was trying to create Review object using "other" db, but when i ran "test_generic_key_deletion" test case only then it passed perfectly.

When i narrowed the problem and run this test case with "test_generic_key_cross_database_protection" then even it gives Error at same line.

In my investigation i found that in "test_generic_key_cross_database_protection" test case, one Reiview object is getting created and because there exist FK relationship with ContentType, content type record for this is getting populated in DB and content type lookup are cached. At the end of this test case, content type record gets cleared by rollback, but content type lookup still remain in cache, so that when inside "test_generic_key_deletion" it tries to create Review object it gets content type from the cache and does not have to go to DB. Next when it tries to populate review table, Integrity error is raised as it has not made entry to contenttype table.

$ python runtests.py --settings=settings_mysql multiple_database.QueryTestCase.test_generic_key_cross_database_protection multiple_database.QueryTestCase.test_generic_key_deletion


Creating test database for alias 'default'...
Creating test database for alias 'other'...
.E
======================================================================
ERROR: test_generic_key_deletion (regressiontests.multiple_database.tests.QueryTestCase)
Cascaded deletions of Generic Key relations issue queries on the right database
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/.../.../.../Django-1.3-rc-1/tests/regressiontests/multiple_database/tests.py", line 825, in test_generic_key_deletion
    review = Review.objects.using('other').create(source="Python Weekly", content_object=dive)
  File "/home/.../.../.../lib/python2.5/site-packages/django/db/models/query.py", line 360, in create
    obj.save(force_insert=True, using=self.db)
  File "/home/.../.../.../lib/python2.5/site-packages/django/db/models/base.py", line 460, in save
    self.save_base(using=using, force_insert=force_insert, force_update=force_update)
  File "/home/.../.../.../lib/python2.5/site-packages/django/db/models/base.py", line 553, in save_base
    result = manager._insert(values, return_id=update_pk, using=using)
  File "/home/.../.../.../lib/python2.5/site-packages/django/db/models/manager.py", line 195, in _insert
    return insert_query(self.model, values, **kwargs)
  File "/home/.../.../.../lib/python2.5/site-packages/django/db/models/query.py", line 1436, in insert_query
    return query.get_compiler(using=using).execute_sql(return_id)
  File "/home/.../.../.../lib/python2.5/site-packages/django/db/models/sql/compiler.py", line 791, in execute_sql
    cursor = super(SQLInsertCompiler, self).execute_sql(None)
  File "/home/.../.../.../lib/python2.5/site-packages/django/db/models/sql/compiler.py", line 735, in execute_sql
    cursor.execute(sql, params)
  File "/home/.../.../.../lib/python2.5/site-packages/django/db/backends/mysql/base.py", line 86, in execute
    return self.cursor.execute(query, args)
  File "/home/.../.../.../lib/python2.5/site-packages/MySQL_python-1.2.3-py2.5-linux-x86_64.egg/MySQLdb/cursors.py", line 174, in execute
    self.errorhandler(self, exc, value)
  File "/home/.../.../.../lib/python2.5/site-packages/MySQL_python-1.2.3-py2.5-linux-x86_64.egg/MySQLdb/connections.py", line 36, in defaulterrorhandler
    raise errorclass, errorvalue
IntegrityError: (1452, 'Cannot add or update a child row: a foreign key constraint fails (`test_testpy2/multiple_database_review`, CONSTRAINT `content_type_id_refs_id_82d6f7ab` FOREIGN KEY (`content_type_id`) REFERENCES `django_content_type` (`id`))')

----------------------------------------------------------------------
Ran 2 tests in 0.040s

FAILED (errors=1)
Destroying test database for alias 'default'...
Destroying test database for alias 'other'...

I am setting storage engine through OPTIONS key of the DATABASES setting as follows:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql', 
        'NAME': 'djangodb1',
        'USER': '****',
        'PASSWORD': '****',
        'HOST': '****',
        'PORT': '****',
        'OPTIONS': {
                'init_command': 'SET storage_engine=INNODB',
        },
    },
    'other': {
	'ENGINE': 'django.db.backends.mysql',
        'NAME': 'djangodb1', 
        'USER': '****', 
        'PASSWORD': '****',
        'HOST': '****',
        'PORT': '****',
        'OPTIONS': {
                'init_command': 'SET storage_engine=INNODB',
        },
	}
}

Attachments (0)

Change History (13)

comment:1 Changed 3 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to worksforme
  • Status changed from new to closed

I can't reproduce this with my INNODB testbed. One possible problem is that your 'other' database isn't actually an 'other' database -- it's an alias to the same database. If I reproduce that condition in my test suite, I get a test failure -- not the one you describe, but a failure nonetheless.

The report doesn't explicitly say that you've run this test with a recent checkout -- the version flag is set to 1.3rc1, but you don't reference the version in the report; it's possible that you might have seen different problems with the database setup you describe if you had an older version of Django.

comment:2 Changed 3 years ago by anonymous

Due to typo setting file shows same database but actually i have run it with two different databases.

I have run it with Django-1.3-beta-1 and Django-1.3rc-1 both, but in both version of Django i got same error as specified in above report.

comment:3 Changed 3 years ago by rahul.priyadarshi@…

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Did you try to reproduce it with two different databases?

comment:4 Changed 3 years ago by russellm

  • Component changed from Uncategorized to Database layer (models, ORM)
  • Triage Stage changed from Unreviewed to Accepted

Ok - reproduced; the key point is that you need to have 2 MySQL InnoDB databases. MySQL + SQLite isn't enough to reproduce the problem.

comment:5 Changed 3 years ago by rahul.priyadarshi@…

Yes. In my case since i was updating the DB2 django adpater for Django 1.3, i was using 2 DB2 databases. FWIW first time we had added value to Django even before a release has been made. Hey am I am getting better at this :-)

comment:6 Changed 3 years ago by rahul.priyadarshi@…

Django-1.3 have been released already, wondering when you are going to resolve this.

comment:7 Changed 3 years ago by russellm

Nobody has presented a patch. It's not on my personal list of criticial bugs that I want to look into (at least -- it's no higher than any other unresolved bug in Django). Based on the fact that no-one else has weighed in, I'm going to guess it isn't a high priority for anyone else, either.

So -- It will be resolved when someone provides a resolution. If this is an important bug for you, then *you* need to be the one to track down the problem.

comment:8 Changed 3 years ago by lukeplant

  • Type set to Bug

comment:9 Changed 3 years ago by lukeplant

  • Severity set to Normal

comment:10 Changed 3 years ago by anonymous

  • Component changed from Database layer (models, ORM) to contrib.contenttypes

comment:11 Changed 2 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:12 Changed 2 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:13 Changed 13 months ago by aaugustin

  • Status changed from reopened to new

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new
The owner will be changed from nobody to anonymous. Next status will be 'assigned'
as The resolution will be set. Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.