Opened 12 years ago
Closed 12 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 , 12 years ago
comment:2 by , 12 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 , 12 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.)