#23100 closed Bug (fixed)
Applying migrations fails when adding a ForeignKey to swappable user model after initial migration
Reported by: | Mattias Linnap | Owned by: | Andrew Godwin |
---|---|---|---|
Component: | Migrations | Version: | 1.7-rc-2 |
Severity: | Release blocker | Keywords: | |
Cc: | Andrew Godwin | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
./manage.py migrate fails with ValueError: Lookup failed for model referenced by field foo.A.owner: accounts.EmailUser
or similar when a ForeignKey to a swapped out user model is added after the initial migration.
Note that both making the migration and applying it work if the ForeignKey to the swappable user model is added in the very first initial migration, but not if it is added later.
I've tested this on both the 1.7 RC1 version, and the latest github checkout of branch "stable/1.7.x".
Steps to reproduce:
- Create a swappable user model, add it to settings.py, create and run migrations.
- Create a new model in a new app. Do not give it a reference to the user model.
- Add a ForeignKey from the new model to the custom user model.
- Run makemigrations. This works.
- Run migrate. This fails.
Workaround:
- Add
migrations.swappable_dependency(settings.AUTH_USER_MODEL),
to the list of dependencies of the failing migration by hand.
Initial investigation:
Swappable user ForeignKeys are referenced as ('owner', models.ForeignKey(to=settings.AUTH_USER_MODEL)),
in the migration scripts.
It seems that if the ForeignKey is added in the initial migration of a new app, then dependencies are correctly added:
dependencies = [ migrations.swappable_dependency(settings.AUTH_USER_MODEL), ]
But if the ForeignKey is added in a later migration, then the initial migration's dependencies are empty, and the second migration's only dependency is:
dependencies = [ ('foo', '0001_initial'), ]
Change History (6)
comment:1 by , 10 years ago
comment:4 by , 10 years ago
Owner: | changed from | to
---|---|
Severity: | Normal → Release blocker |
Status: | new → assigned |
Closed #22944 in favour of this, promoting this to release blocker.
comment:5 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Sorry, I missed a step in the reproduction instructions. They are: