Opened 10 years ago

Closed 6 years ago

Last modified 6 years ago

#22395 closed Bug (fixed)

Deleting a model and fields that relate to it results in ValueError: Related model '<app>.<model>' cannot be resolved

Reported by: Stephen Burrows Owned by: nobody
Component: Migrations Version: 2.0
Severity: Normal Keywords:
Cc: Stephen Burrows Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

This seems to happen because a single migration is created which both deletes the model and the fields that reference it - but the fields are (sometimes?) deleted second, so the model is already "gone" by the time the migration gets that far.

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

Change History (10)

comment:1 by Tim Graham, 10 years ago

Triage Stage: UnreviewedAccepted

comment:2 by ofirov, 10 years ago

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 reproduces the bug?

Last edited 10 years ago by ofirov (previous) (diff)

comment:3 by andrewsg, 10 years ago

This looks potentially related to the root cause of #22397 and it's possible my work on that bug will affect this one.

comment:4 by Stephen Burrows, 10 years ago

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.

Version 0, edited 10 years ago by Stephen Burrows (next)

comment:5 by Stephen Burrows, 10 years ago

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.

comment:6 by Tim Graham, 10 years ago

@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.

comment:7 by Stephen Burrows, 10 years ago

@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

comment:8 by Tim Graham, 10 years ago

Resolution: fixed
Status: newclosed

comment:9 by Dan Watson, 6 years ago

Resolution: fixed
Status: closednew
Version: 1.7-beta-12.0

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.

comment:10 by Simon Charette, 6 years ago

Resolution: fixed
Status: newclosed

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 that orders operations inappropriately.

Last edited 6 years ago by Simon Charette (previous) (diff)
Note: See TracTickets for help on using tickets.
Back to Top