#22470 closed Bug (fixed)
Migrations fail with order_with_respect_to and ForeignKey to self
| Reported by: | Jonas von Poser | Owned by: | Andrew Godwin |
|---|---|---|---|
| Component: | Migrations | Version: | 1.7-beta-1 |
| Severity: | Release blocker | Keywords: | migrations order_with_respect_to |
| Cc: | Jonas von Poser, Shai Berger, jezevec, beathan | Triage Stage: | Accepted |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Initial migrations for an app with this kind of model setup will fail when running ./manage.py migrate:
class Parent(models.Model): spouse = models.ForeignKey('self') class Child(models.Model): parent = models.ForeignKey(Parent) class Meta: order_with_respect_to = 'parent'
This is the resulting traceback:
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/home/jonas/temp/django/django/core/management/__init__.py", line 427, in execute_from_command_line
utility.execute()
File "/home/jonas/temp/django/django/core/management/__init__.py", line 419, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/jonas/temp/django/django/core/management/base.py", line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File "/home/jonas/temp/django/django/core/management/base.py", line 337, in execute
output = self.handle(*args, **options)
File "/home/jonas/temp/django/django/core/management/commands/migrate.py", line 145, in handle
executor.migrate(targets, plan, fake=options.get("fake", False))
File "/home/jonas/temp/django/django/db/migrations/executor.py", line 60, in migrate
self.apply_migration(migration, fake=fake)
File "/home/jonas/temp/django/django/db/migrations/executor.py", line 88, in apply_migration
if self.detect_soft_applied(migration):
File "/home/jonas/temp/django/django/db/migrations/executor.py", line 132, in detect_soft_applied
apps = project_state.render()
File "/home/jonas/temp/django/django/db/migrations/state.py", line 48, in render
model.render(self.apps)
File "/home/jonas/temp/django/django/db/migrations/state.py", line 232, in render
body,
File "/home/jonas/temp/django/django/db/models/base.py", line 298, in __new__
new_class._prepare()
File "/home/jonas/temp/django/django/db/models/base.py", line 322, in _prepare
opts._prepare(cls)
File "/home/jonas/temp/django/django/db/models/options.py", line 180, in _prepare
self.order_with_respect_to = self.get_field(self.order_with_respect_to)
File "/home/jonas/temp/django/django/db/models/options.py", line 397, in get_field
raise FieldDoesNotExist('%s has no field named %r' % (self.object_name, name))
django.db.models.fields.FieldDoesNotExist: Child has no field named 'parent'
makemigrations creates three migrations:
- The first migration creates the
Childmodel without theparentfield as well as theParentmodel without thespousefield. - The second migration adds the
spousefield toParent. - The third migration adds
parenttoChild.
The error occurs in the first migration, when the _prepare() wants to access the parent field for order_with_respect_to and can't, as it doesn't exist yet.
I tried adding a test in Django proper but wasn't able to. Will keep trying but support is appreciated.
Change History (11)
comment:1 by , 12 years ago
| Cc: | added |
|---|
comment:2 by , 12 years ago
| Severity: | Normal → Release blocker |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
comment:3 by , 11 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:4 by , 11 years ago
| Cc: | added |
|---|
This is odd. I'd expect all the fields to be created immediately, and only the constraint creation to be delayed.
comment:5 by , 11 years ago
Hmm, that might be possible - we could replace the AddField(ForeignKey) with AddField(IntegerField) (or whatever the underlying type is) and then have the second thing be the AlterField to a ForeignKey. I'll try that approach.
comment:6 by , 11 years ago
| Cc: | added |
|---|
comment:7 by , 11 years ago
| Cc: | added |
|---|
comment:8 by , 11 years ago
Just noting that this will be fixed as part of the big autodetector rewrite.
comment:9 by , 11 years ago
This didn't land in the main autodetector merge, but it can now be fixed as that's in place. I plan to add a new operation for alterations to order_with_respect_to (or perhaps just alteration of model options in general) and implement that with proper dependency to fix this.
comment:10 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Urgh, this is nasty. I'm going to have to find some way of pushing back all Meta changes along with delayed ForeignKeys (this bug will also occur for index_together and unique_together among others).