Database out of sync with migrations

Using Django Mystery Errors
1

When I try to migrate, I’m getting the following errors:

[standard:public] === Starting migration
[standard:public] Operations to perform:
[standard:public]   Apply all migrations: accounts, admin, assets, auth, companies, contenttypes, costs, customers, dispatchers, django_q, drivers, loads, sessions, subsidiaries, summary, trips
Traceback (most recent call last):
  File "/Users/valeriu/Sites/FleetData/manage.py", line 22, in <module>
    main()
  File "/Users/valeriu/Sites/FleetData/manage.py", line 18, in main
    execute_from_command_line(sys.argv)
  File "/Users/valeriu/Sites/FleetData/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 442, in execute_from_command_line
    utility.execute()
  File "/Users/valeriu/Sites/FleetData/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 436, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Users/valeriu/Sites/FleetData/venv/lib/python3.10/site-packages/django/core/management/base.py", line 412, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/Users/valeriu/Sites/FleetData/venv/lib/python3.10/site-packages/django/core/management/base.py", line 458, in execute
    output = self.handle(*args, **options)
  File "/Users/valeriu/Sites/FleetData/venv/lib/python3.10/site-packages/django_tenants/management/commands/migrate_schemas.py", line 63, in handle
    executor.run_migrations(tenants=[self.PUBLIC_SCHEMA_NAME])
  File "/Users/valeriu/Sites/FleetData/venv/lib/python3.10/site-packages/django_tenants/migration_executors/standard.py", line 11, in run_migrations
    run_migrations(self.args, self.options, self.codename, self.PUBLIC_SCHEMA_NAME)
  File "/Users/valeriu/Sites/FleetData/venv/lib/python3.10/site-packages/django_tenants/migration_executors/base.py", line 59, in run_migrations
    migrate_command_class(stdout=stdout, stderr=stderr).execute(*args, **options)
  File "/Users/valeriu/Sites/FleetData/venv/lib/python3.10/site-packages/django/core/management/base.py", line 458, in execute
    output = self.handle(*args, **options)
  File "/Users/valeriu/Sites/FleetData/venv/lib/python3.10/site-packages/django/core/management/base.py", line 106, in wrapper
    res = handle_func(*args, **kwargs)
  File "/Users/valeriu/Sites/FleetData/venv/lib/python3.10/site-packages/django/core/management/commands/migrate.py", line 302, in handle
    pre_migrate_apps = pre_migrate_state.apps
  File "/Users/valeriu/Sites/FleetData/venv/lib/python3.10/site-packages/django/utils/functional.py", line 57, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/Users/valeriu/Sites/FleetData/venv/lib/python3.10/site-packages/django/db/migrations/state.py", line 566, in apps
    return StateApps(self.real_apps, self.models)
  File "/Users/valeriu/Sites/FleetData/venv/lib/python3.10/site-packages/django/db/migrations/state.py", line 637, in __init__
    raise ValueError("\n".join(error.msg for error in errors))
ValueError: The field assets.TruckToDriverAssignment.dispatcher was declared with a lazy reference to 'dispatchers.dispatcher', but app 'dispatchers' isn't installed.
The field drivers.Driver.dispatcher was declared with a lazy reference to 'dispatchers.dispatcher', but app 'dispatchers' isn't installed.
The field loads.Load.sales_agent was declared with a lazy reference to 'dispatchers.dispatcher', but app 'dispatchers' isn't installed.
The field trips.Trip.dispatcher was declared with a lazy reference to 'dispatchers.dispatcher', but app 'dispatchers' isn't installed.

class Driver(models.Model):
    dispatcher = models.ForeignKey(Dispatcher, on_delete=models.DO_NOTHING, null=True, blank=True)
    ....

class TruckToDriverAssignment(models.Model):
    dispatcher = models.ForeignKey(Dispatcher, on_delete=models.CASCADE, null=True, blank=True)
    ...

class Load(models.Model):
    sales_agent = models.ForeignKey(Dispatcher, on_delete=models.DO_NOTHING, related_name='sales_agent_loads', blank=True, null=True)
    ....

class Trip(models.Model):
    dispatcher = models.ForeignKey(Dispatcher, on_delete=models.CASCADE, null=True, blank=True)

All these migration problems started when I switched a ForeignKey model reference from one model to another (first added a new field with the new reference, then changed the data in the table, then removed the old field with the reference).

I can’t seem to find more info anywhere. Any help highly appreciated.

2

BTW, at some point I deleted all migrations in the ‘dispatchers’ app and all rows in the ‘django-migrations’ table where app = ‘dispatchers’

3

You will also need to look for any other migrations that may have had a reference to that app, and resolve those as well.

4

If you’re deleting rows from the migrations table without changing the schema, you’re in for a bad time. I wrote a walk-through on a similar problem that may be useful to you when you’re out of the woods with this.

If you’re still in development and don’t need any of the data, you’re probably best declaring migration bankruptcy and starting with a fresh db and deleting all the migrations and re-creating them. The alternative is fairly tedious because you have to get your migration project state to match your database schema.

5

Thank you both Ken and Tim.

I eventually had to declare a partial migration bankruptcy (lol) and completely emptied the django_migrations table, removed all migration files from all apps and faked initial migrations. All other tables are intact and I’m not getting any errors anymore. Drastic times call for drastic measures, right?

This is an app that I’m working on for learning purposes and am a solo dev, so should be fine. The lesson I’m taking from this (and from your article Tim) is to never mess with the db or migration files, at least until I’m confident I know what I’m doing.

6

I mean, you’re definitely allowed to make changes. Just do it in a test environment first and confirm the changes did what you’d like. There are scripts you can run to compare schema and checksums of data. I have to look up them every time, but they do exist.

1 Like
7

This is actually a good principle to follow.

I look at it this way - these migrations files are as much a part of your project code as your views, models, and forms files.

You wouldn’t go deleting or editing those files without consider the implications of doing that. You should treat your migration files with the same respect.

The fact that Django has created the migration files doesn’t make them any less critical to the proper operation of your system.

2 Likes