Backward migration failing because of old dropped model

[Adrien Agnel]

Hi everyone,

This is my first post in this group so do not hesitate to ask for some more specific details if this is not enough. Django version is 2.2.9, Python 3.6.

I'm facing an error when trying to migrate back the initial migration of a freshly installed new application 'billing'.

The error message is the following one : 

ValueError: The field form.Form.ticket_description was declared with a lazy reference to 'tickets.ticketdescription', but app 'tickets' doesn't provide model 'ticketdescription'.

However the model 'ticketdescription' has been dropped several month ago and is no longer present in my project. Thus the part " app 'tickets' doesn't provide model 'ticketdescription' " is perfectly right, but I don't get why it is not managed by the migration of app 'tickets' which dropped the model 'ticketdescription'.

The model 'ticketdescription' remains as a pending model of state apps in the migration executor, I would expect it to be removed.

Until now, I could migrate backward other apps without any issue but after adding the app 'billing', which is not directly related to app 'tickets', it is not possible anymore.

I don't know where to look at to fix this issue ? Could you help me debugging please ? This looks like a bug but I'm not sure !

Best regards,

Adrien

 

Here is the full error trace :

Traceback (most recent call last):
  File "manage.py", line 23, in <module>
    execute_from_command_line(sys.argv)
  File "[...]/lib/python3.6/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
    utility.execute()
  File "[...]/lib/python3.6/site-packages/django/core/management/__init__.py", line 375, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "[...]/lib/python3.6/site-packages/django/core/management/base.py", line 323, in run_from_argv
    self.execute(*args, **cmd_options)
  File "[...]/lib/python3.6/site-packages/django/core/management/base.py", line 364, in execute
    output = self.handle(*args, **options)
  File "[...]/lib/python3.6/site-packages/django/core/management/base.py", line 83, in wrapped
    res = handle_func(*args, **kwargs)
  File "[...]/lib/python3.6/site-packages/django/core/management/commands/migrate.py", line 234, in handle
    fake_initial=fake_initial,
  File "[...]/lib/python3.6/site-packages/django/db/migrations/executor.py", line 121, in migrate
    state = self._migrate_all_backwards(plan, full_plan, fake=fake)
  File "[...]/lib/python3.6/site-packages/django/db/migrations/executor.py", line 173, in _migrate_all_backwards
    for migration, _ in full_plan:
  File "[...]/lib/python3.6/site-packages/django/utils/functional.py", line 80, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "[...]/lib/python3.6/site-packages/django/db/migrations/state.py", line 210, in apps
    return StateApps(self.real_apps, self.models)
  File "[...]/lib/python3.6/site-packages/django/db/migrations/state.py", line 280, in __init__
    raise ValueError("\n".join(error.msg for error in errors))
ValueError: The field form.Form.ticket_description was declared with a lazy reference to 'tickets.ticketdescription', but app 'tickets' doesn't provide model 'ticketdescription'.

[Bruckner de Villiers]

Adrien,

Your precise issue eludes me, but I have sometimes come across a similar issue when changing the field types of models. 

It appears that you still have a reference somewhere in your code between the form and the model.  I suspect that form.Form.ticket_description is a Django default expected file name from one of your (original) CBV’s.

 

Alternative:

My method to resolve the Catch22 is to delete the most recent migration files, including in your case, the migration file that originally created the ‘ticketdescription’ model.  I move them to a dummy folder, in case they shouldn’t have been deleted.

 

Bruckner de Villiers

083 625 1086

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/4f876052-71e5-4d25-9382-59d3c30d19f8%40googlegroups.com.

[maninder singh Kumar]

In your database there is a table called django_migrations.  Delete all references in it to any other migration than the initial one.

Maninder Kumar about.me/maninder.s.kumar

--

[Adrien Agnel]

Hello Bruckner,

Thank you for your answer. You pointed me in the right direction : the issue was with the Form model which is part of a custom app named 'form'...

I've added a depency to the initial migration of the 'billing' app on the last current migration of 'form' app, and it solved the issue : the states are now correctly rendered !

I don't get how the migration graph was built before that new dependency, but it's fine this way.

I guess I will have to clean all the migration files, there are plenty of them in my project.

Thanks again,

Best regards,

Adrien

To unsubscribe from this group and stop receiving emails from it, send an email to django...@googlegroups.com.

[Adrien Agnel]

Hello Maninder,

Thanks for your answer, it's finally working now after adding a dependency to the initial migration file.

See Bruckner's answer and my other reply for more details.

Best regards,

Adrien

To unsubscribe from this group and stop receiving emails from it, send an email to django...@googlegroups.com.

[Adrien Agnel]

I have been a bit quick when I wrote that this finally works...

Actually, with the dependency on 'form' app, I can now run my new migration for the 'billing' app and make it work backward as well.

However my project's test suites won't run anymore, and fail with the same error as previously.

I have checked for references of the field `ticket_description`, which seems to be causing the issue, there is no more reference to the 'ticketdescription' model which has been dropped and the field has been changed from a ForeignKey to a simple CharField, all the migrations making theses changes are well present.

I do not get why adding a new app messes up the migrations that way.

This looks like a bug, doesn't it ? Any idea about how to investigate it further ?

Regards,

Adrien