Opened 8 years ago

Last modified 8 years ago

#27422 closed Bug

`makemigrations` fails to migrate ForeignKey types across app boundaries — at Version 2

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 Andrew Badr)

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:

  1. Create Model A
  2. Create Model B with a ForeignKey to Model A
  3. Alter the type of the primary key on A, e.g. making it a BigInteger
  4. 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 (2)

comment:1 by Andrew Badr, 8 years ago

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.

comment:2 by Andrew Badr, 8 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.
Back to Top