Opened 11 years ago
Closed 11 years ago
#22518 closed Bug (duplicate)
Migrations broken with custom user model
Reported by: | Stephen Burrows | Owned by: | nobody |
---|---|---|---|
Component: | Migrations | Version: | 1.7-beta-2 |
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
This is *not* the same bug as #22325, though it may be related. Also related to #22397 (in that the fix there caused this bug to appear).
I only know this is related to custom user models because migrations work fine if I remove the setting (and convert the custom user model to a normal model) and *then* generate and run them.
To reproduce:
- Make an app with a custom user model and a few migrations
- Remove all references to
migrations.swappable_dependency(settings.AUTH_USER_MODEL)
as a workaround for #22325 - Migrations fail.
If that doesn't work, or if you'd like to skip that step, you can just use https://github.com/littleweaver/django-brambling@e6f9b24f69d56c1a33a3c737596690b685c3a68a
The migrations fail like this:
$ ./manage.py migrate Operations to perform: Synchronize unmigrated apps: floppyforms, sessions, admin, auth, zenaida, contenttypes Apply all migrations: brambling, auth Synchronizing apps without migrations: Creating tables... Creating table django_admin_log Creating table auth_permission Creating table auth_group_permissions Creating table auth_group Creating table django_content_type Creating table django_session Installing custom SQL... Installing indexes... Running migrations: Applying brambling.0001_initial... OK Applying brambling.0002_eventhousing_eventperson_home_housingslot_itemoption_payment_person_persondiscount...Traceback (most recent call last): File "./manage.py", line 10, in <module> execute_from_command_line(sys.argv) File ".../django/django/core/management/__init__.py", line 427, in execute_from_command_line utility.execute() File ".../django/django/core/management/__init__.py", line 419, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File ".../django/django/core/management/base.py", line 288, in run_from_argv self.execute(*args, **options.__dict__) File ".../django/django/core/management/base.py", line 337, in execute output = self.handle(*args, **options) File ".../django/django/core/management/commands/migrate.py", line 145, in handle executor.migrate(targets, plan, fake=options.get("fake", False)) File ".../django/django/db/migrations/executor.py", line 60, in migrate self.apply_migration(migration, fake=fake) File ".../django/django/db/migrations/executor.py", line 88, in apply_migration if self.detect_soft_applied(migration): File ".../django/django/db/migrations/executor.py", line 132, in detect_soft_applied apps = project_state.render() File ".../django/django/db/migrations/state.py", line 63, in render model=dangling_lookup[0])) ValueError: Lookup failed for model referenced by field auth.Permission.content_type: contenttypes.ContentType
This bug exists in stable/1.7.x and master. I've already tried re-generating the migrations.
Change History (4)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Workaround: tweaking the autogenerated migration's dependencies like so:
dependencies = [ ('auth', '__first__'), ('contenttypes', '__first__'), # Added this line ('brambling', '0001_initial'), ]
comment:3 by , 11 years ago
Severity: | Release blocker → Normal |
---|
Interesting to note is that contenttypes *is migrated*, so this *should* work. My guess is that the migration isn't including the contenttypes app in the fake ORM, because it doesn't expect to need them. The first migration that's failing is the one where the custom user model is introduced. (All subsequent migrations also fail with this error if you get to them by using an older django commit.)