Workaround is to move the field deletions up in the migrations file to
*before* the model deletion.
Generated migration (relevant bits):
{{{
[...]
class Migration(migrations.Migration):
operations = [
migrations.DeleteModel(
name='House',
),
migrations.RemoveField(
model_name='housingslot',
name='house',
),
migrations.RemoveField(
model_name='person',
name='house',
),
]
}}}
Traceback:
{{{
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 94, in
apply_migration
migration.apply(project_state, schema_editor)
File ".../django/django/db/migrations/migration.py", line 97, in apply
operation.database_forwards(self.app_label, schema_editor,
project_state, new_state)
File ".../django/django/db/migrations/operations/fields.py", line 36, in
database_forwards
field,
File ".../django/django/db/backends/sqlite3/schema.py", line 117, in
add_field
self._remake_table(model, create_fields=[field])
File ".../django/django/db/backends/sqlite3/schema.py", line 84, in
_remake_table
self.create_model(temp_model)
File ".../django/django/db/backends/schema.py", line 191, in
create_model
definition, extra_params = self.column_sql(model, field)
File ".../django/django/db/backends/schema.py", line 108, in column_sql
db_params = field.db_parameters(connection=self.connection)
File ".../django/django/db/models/fields/related.py", line 1758, in
db_parameters
return {"type": self.db_type(connection), "check": []}
File ".../django/django/db/models/fields/related.py", line 1749, in
db_type
rel_field = self.related_field
File ".../django/django/db/models/fields/related.py", line 1655, in
related_field
return self.foreign_related_fields[0]
File ".../django/django/db/models/fields/related.py", line 1414, in
foreign_related_fields
return tuple(rhs_field for lhs_field, rhs_field in
self.related_fields)
File ".../django/django/db/models/fields/related.py", line 1401, in
related_fields
self._related_fields = self.resolve_related_fields()
File ".../django/django/db/models/fields/related.py", line 1386, in
resolve_related_fields
raise ValueError('Related model %r cannot be resolved' % self.rel.to)
ValueError: Related model 'brambling.House' cannot be resolved
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22395>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_docs: => 0
* needs_tests: => 0
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/22395#comment:1>
Comment (by ofirov):
I couldn't reproduce the bug. Not on stable (f004374) and not on the 1.7b1
tag. I tried the following:
https://github.com/Ofir-Purple/django/tree/testing-22395
https://github.com/Ofir-Purple/django/tree/testing-22395-on-1.7b1
And tried to create a project with 2 related fields. I made sure that the
migration's operations were: First delete the model, then the related
fields; But to no avail. The migrations worked fine.
Do you have a link to a full project that reproduced the bug?
--
Ticket URL: <https://code.djangoproject.com/ticket/22395#comment:2>
Comment (by andrewsg):
This looks potentially related to the root cause of #22397 and it's
possible my work on that bug will affect this one.
--
Ticket URL: <https://code.djangoproject.com/ticket/22395#comment:3>
Comment (by melinath):
I'm technically running 1.7.X, not the 1.7b1 tag. So it could be a newly-
introduced bug. I'll test.
The project I'm using is https://github.com/littleweaver/django-brambling
- but I never committed the broken version. Worked around by deleting,
then recreating the broken fields (since we're still in alpha and hadn't
put any data in there yet.)
I'll pull the latest 1.7.X and see if it's been fixed.
--
Ticket URL: <https://code.djangoproject.com/ticket/22395#comment:4>
Comment (by melinath):
I can't reproduce this exact bug any more in 1.7.X while migrating
forward, but it does still show up in reverse migrations.
It does look like this will probably be resolved by #22397.
--
Ticket URL: <https://code.djangoproject.com/ticket/22395#comment:5>
Comment (by timo):
@melinath, could you check if this is still an issue as the ticket you
referenced above has been resolved? If it still is, some steps to
reproduce would be helpful, as it will be easier than reversing them from
the details you've provided.
--
Ticket URL: <https://code.djangoproject.com/ticket/22395#comment:6>
Comment (by melinath):
@timo: Yeah, seems fixed. But to find that out I have to checkout
a6ecd5dbb34249f756a337c359eef1e8d78dc01e (to avoid #22563) then checkout
stable/1.7.x to make the migration. So... yeah, it has been fixed,
probably :-p
--
Ticket URL: <https://code.djangoproject.com/ticket/22395#comment:7>
* status: new => closed
* resolution: => fixed
--
Ticket URL: <https://code.djangoproject.com/ticket/22395#comment:8>
* status: closed => new
* version: 1.7-beta-1 => 2.0
* resolution: fixed =>
Comment:
I ran into this bug today using Django 2.0.8, so I think it can still crop
up. It's an easy workaround, as mentioned above, but happening
nonetheless. I'll try to find some time to write a test case to reproduce
it.
--
Ticket URL: <https://code.djangoproject.com/ticket/22395#comment:9>
* status: new => closed
* resolution: => fixed
Comment:
Dan, it is possible that the migrations were generated before the issue
was fixed?
If it's the case the bug will be present on any version of Django as long
as the migration operations are not re-ordered manually.
Please file a new ticket referencing this one if you manage to reproduce a
`makemigrations` call the orders operations inappropriately.
--
Ticket URL: <https://code.djangoproject.com/ticket/22395#comment:10>