Opened 8 years ago
Closed 8 years ago
#27422 closed Bug (invalid)
`makemigrations` fails to migrate ForeignKey types across app boundaries
Reported by: | Andrew Badr | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.10 |
Severity: | Normal | 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 (last modified by )
I am using django-social-auth and a custom User model. I changed my User model to use a BigInteger id
field. Everything looked ok, and I pushed into production, then started getting not-super-informative exceptions about integer out of range
. I tracked it down to this bug—specifically, I have a django-social-auth model with a foreignkey to User—and I was able to reproduce it on a clean Django project. This kind of migration should either work correctly or raise an error.
Steps to reproduce:
- Create Model A
- Create Model B with a ForeignKey to Model A
- Alter the type of the primary key on A, e.g. making it a BigInteger
- manage.py makemigrations and migrate
Expected behavior:
The type of the foreign-key column in the table for column B is changed to the new type.
Actual behavior:
The type of the foreign-key column in the table for column B is changed to the new type if and only if A and B are in the same app.
Change History (3)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
Description: | modified (diff) |
---|
comment:3 by , 8 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Oops— I think I need to dig into this more. Sorry!
Note also that this is a pain to work around. It's too late to roll back the bigint ids (they are on all my models), and I don't know how to force the foreignkey type change in a 3rd party app (I can't edit django-social-auth's models) without bringing a local copy into my project. Right now my plan is to alter the production db manually.