id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
30966	Migration crashes due to foreign key issue, depending on otherwise irrelevant order on MySQL.	Peter Thomassen	Hasan Ramezani	"In my Django app ""desecapi"" (reduced to a minimal example), I have two migrations. The first migration defines the following models:

User
+ Token (Token.user relates to User.id)
+ Domain (Domain.owner relates to User.id)
...+ RRset (RRset.domain relates to Domain.id)

... where ""+"" denotes foreign-key relationships. Note that RRset is a grandchild of User.


When running the two migrations together on an empty database (i.e. running `python manage.py desecapi 0002` instead of `... 0001` and `... 0002` separately), the second migration fails with:

`django.db.utils.OperationalError: (1833, ""Cannot change column 'id': used in a foreign key constraint 'desecapi_token_user_id_bfc397b3_fk_desecapi_user_id' of table 'desec.desecapi_token'"")`

When running them separately, both migrations work. I would expect that running in bulk or each on its own should not make a difference.

The issue can be fixed by switching the order of two operations in the first migration. One of these two operations is the one that creates the `desecapi_token` table (mentioned in the above error), and the other operation changes an attribute of the RRset.subname field. That model is not related to the Token model, and also not directly related to the User model (which is touch in the second migration).

I would not expect this ordering to influence whether the second migration can run successfully or not.

(One can say that the operation changing RRset.subname is unnecessary, as it could be incorporated in RRset's ""CreateModel"" operation. However, the history of encountering the problem is that RRset.subname in fact was changed in an intermediate migration. It just seems unnecessary because this minimal example is very much reduced.)


The minimal example can be found here: https://github.com/peterthomassen/django-bug/tree/master/api/desecapi
Note that in the interest of having a minimal example, models.py does not contain all models that the migrations deal with. My understanding is that that's fine (think of the missing models and fields as removed, but there is no migration yet that reflects that).


I created a docker-compose application that sets up an empty database and reproduces the problem. To reproduce, run the following:

git clone https://github.com/peterthomassen/django-bug.git
cd django-bug/
docker-compose build
docker-compose up -d dbapi    # after this, wait for 2-3 minutes so that the database is up
docker-compose run api bash
# now, at the container shell, compare
python manage.py migrate desecapi 0002
# vs   (make sure to clean up the database)
python manage.py migrate desecapi 0001
python manage.py migrate desecapi 0002
"	Bug	closed	Migrations	dev	Normal	fixed	migration mySQL	Simon Charette Markus Holtermann	Accepted	1	0	0	0	0	0