#30966: Migration crashes due to index issue, depending on otherwise irrelevant
order
-------------------------------------+-------------------------------------
Reporter: Peter | Owner: nobody
Thomassen |
Type: Bug | Status: new
Component: Database | Version: 2.2
layer (models, ORM) |
Severity: Normal | Keywords: migration
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
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
--
Ticket URL: <https://code.djangoproject.com/ticket/30966>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/057.ed5a23c04bdf667fc7599bd662e1e006%40djangoproject.com.
