Opened 9 years ago
Last modified 9 years ago
#25140 closed Bug
Error when running test with MySQL database — at Initial Version
Reported by: | luccascorrea | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.8 |
Severity: | Release blocker | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I am running into this error when I try to test an app using a MySQL database. I get an IntegrityError(1215, 'Cannot add foreign key constraint')" while creating the tables.
What is happenning is this: I have a model called SyncLog which has a foreign key to another model called UserEmployee. The error happens when this foreign key is added.
I checked the history of queries run by Django while creating the table and the results are below shown. What I can see is that Django starts creating the SyncLog table before the UserEmployee table and, because that table does not exist yet, the creation fails. I would suppose that there is a bug when determining the dependencies between models in order to determine the order the tables should be created.
CREATE DATABASE test_compras
set autocommit=0
set autocommit=1
SET SQL_AUTO_IS_NULL = 0
SHOW FULL TABLES
CREATE TABLE django_migrations
(id
integer AUTO_INCREMENT NOT NULL PRIMARY KEY, app
varchar(255) NOT NULL, name
varchar(255) NOT NULL, applied
datetime(6) NOT NULL)
SELECT engine FROM information_schema.tables WHERE table_name = \django_migrations\
SELECT django_migrations
.app
, django_migrations
.name
FROM django_migrations
SHOW FULL TABLES
set autocommit=0
CREATE TABLE e89_syncing_synclog
(id
integer AUTO_INCREMENT NOT NULL PRIMARY KEY, user_id
integer NOT NULL, timestamp
datetime(6) NOT NULL, identifier
varchar(100) NOT NULL)
SELECT engine FROM information_schema.tables WHERE table_name = \e89_syncing_synclog\
CREATE TABLE e89_tools_keyvaluestore
(id
integer AUTO_INCREMENT NOT NULL PRIMARY KEY, key
varchar(255) NOT NULL UNIQUE, value
longtext NOT NULL)
SELECT engine FROM information_schema.tables WHERE table_name = \e89_tools_keyvaluestore\
CREATE TABLE e89_push_messaging_device
(id
integer AUTO_INCREMENT NOT NULL PRIMARY KEY, owner_id
integer NOT NULL, registration_id
varchar(200) NOT NULL, platform
varchar(30) NOT NULL, UNIQUE (registration_id
, platform
))
SELECT engine FROM information_schema.tables WHERE table_name = \e89_push_messaging_device\
CREATE TABLE e89_beta_testing_betatester
(id
integer AUTO_INCREMENT NOT NULL PRIMARY KEY, email
varchar(255) NOT NULL UNIQUE, name
varchar(255) NOT NULL, platform
varchar(30) NULL, udid
varchar(255) NULL, phone
varchar(20) NOT NULL, token
varchar(50) NOT NULL)
SELECT engine FROM information_schema.tables WHERE table_name = \e89_beta_testing_betatester\
CREATE TABLE e89_beta_testing_iphonebetaapp
(id
integer AUTO_INCREMENT NOT NULL PRIMARY KEY, plist_url
varchar(300) NULL, ipa
varchar(100) NOT NULL, plist
varchar(100) NOT NULL)
SELECT engine FROM information_schema.tables WHERE table_name = \e89_beta_testing_iphonebetaapp\
ALTER TABLE e89_syncing_synclog
ADD CONSTRAINT e89_syncing_user_id_670069ad1cf9eaae_fk_accounts_useremployee_id
FOREIGN KEY (user_id
) REFERENCES accounts_useremployee
(id
)
rollback
set autocommit=1
The stacktrace I get is pasted below:
IntegrityError: (1215, 'Cannot add foreign key constraint')
File "raven/contrib/django/management/init.py", line 41, in new_execute
File "django/core/management/base.py", line 444, in execute
File "django/core/management/commands/migrate.py", line 179, in handle
File "django/core/management/commands/migrate.py", line 317, in sync_apps
File "django/db/backends/utils.py", line 64, in execute
File "django/db/utils.py", line 97, in exit
File "django/db/backends/utils.py", line 62, in execute
File "django/db/backends/mysql/base.py", line 124, in execute
File "MySQLdb/cursors.py", line 205, in execute
File "MySQLdb/connections.py", line 36, in defaulterrorhandler
I ran the same test with Django 1.7.9 and it worked fine.
I am using Sentry to monitor exceptions and I have their full stack trace with variable values and all. I will not paste it here because it's too long and kind of hard to read but I will attach it as a separate file because I believe it could help identifying the cause of this bug.
Json with the stacktrace generated by Sentry. It contains variable values at the moment the exception occurred.