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.

Change History (1)

by luccascorrea, 9 years ago

Attachment: sentry_log.txt added

Json with the stacktrace generated by Sentry. It contains variable values at the moment the exception occurred.

Note: See TracTickets for help on using tickets.
Back to Top