#21958 closed Bug (fixed)

Migrations fail on adding ForeignKey field to User model

Reported by: code22 Owned by: Andrew Godwin <andrew@…>
Component: Migrations Version: 1.7-alpha-1
Severity: Release blocker Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


It seems that migrations have problems with adding columns with foreign key to User tables. This happens both if I use settings.AUTH_USER_MODEL and django.contrib.auth.model.User.

My model looked like this:

class TestModel(models.Model):

    text = models.CharField(max_length=10)

so if I add User field

class TestModel(models.Model):

    text = models.CharField(max_length=10)
    user = models.ForeignKey(settings.AUTH_USER_MODEL, null=True)

then run manage.py makemigrations and then manage.py migrate I get this:

Operations to perform:
  Synchronize unmigrated apps: admin, contenttypes, auth, sessions
  Apply all migrations: migr_test
Synchronizing apps without migrations:
  Creating tables...
  Installing custom SQL...
  Installing indexes...
Installed 0 object(s) from 0 fixture(s)
Running migrations:
  Applying migr_test.0002_testmodel_user...Traceback (most recent call last):
  File "./manage.py", line 10, in <module>
  File "/private/tmp/test_env/src/django/django/core/management/__init__.py", line 427, in execute_from_command_line
  File "/private/tmp/test_env/src/django/django/core/management/__init__.py", line 419, in execute
  File "/private/tmp/test_env/src/django/django/core/management/base.py", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/private/tmp/test_env/src/django/django/core/management/base.py", line 337, in execute
    output = self.handle(*args, **options)
  File "/private/tmp/test_env/src/django/django/core/management/commands/migrate.py", line 145, in handle
    executor.migrate(targets, plan, fake=options.get("fake", False))
  File "/private/tmp/test_env/src/django/django/db/migrations/executor.py", line 60, in migrate
    self.apply_migration(migration, fake=fake)
  File "/private/tmp/test_env/src/django/django/db/migrations/executor.py", line 94, in apply_migration
    migration.apply(project_state, schema_editor)
  File "/private/tmp/test_env/src/django/django/db/migrations/migration.py", line 97, in apply
    operation.database_forwards(self.app_label, schema_editor, project_state, new_state)
  File "/private/tmp/test_env/src/django/django/db/migrations/operations/fields.py", line 35, in database_forwards
  File "/private/tmp/test_env/src/django/django/db/backends/sqlite3/schema.py", line 96, in add_field
    self._remake_table(model, create_fields=[field])
  File "/private/tmp/test_env/src/django/django/db/backends/sqlite3/schema.py", line 33, in _remake_table
    if field.get_default():
  File "/private/tmp/test_env/src/django/django/db/models/fields/related.py", line 1649, in get_default
    if isinstance(field_default, self.rel.to):
TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types

Used Python3.3.3 and Python2.7.6 with the same result

Change History (4)

comment:1 Changed 20 months ago by aaugustin

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Severity changed from Normal to Release blocker
  • Triage Stage changed from Unreviewed to Accepted

This looks like a bug with swappable models.

comment:2 Changed 20 months ago by Andrew Godwin <andrew@…>

  • Owner set to Andrew Godwin <andrew@…>
  • Resolution set to fixed
  • Status changed from new to closed

In 11c021336c8cb1c92be998f1a44c89a746275107:

Fixed #21958: Handle dependencies for swappable models in AddField

comment:3 Changed 18 months ago by snanda85@…

  • Resolution fixed deleted
  • Status changed from closed to new

Dependency handling should also be done for "NOT NULL fields with no default"

comment:4 Changed 18 months ago by andrewgodwin

  • Resolution set to fixed
  • Status changed from new to closed

Please open a new ticket and explain the bug more fully; it's the not the same as this bug, so please don't re-open it unless you've found the same problem as before.

Note: See TracTickets for help on using tickets.
Back to Top