Django migrations error KeyError: ('list', u'user')

Question

I am trying to run

python manage.py migrate

or

python manage.py makemigrations

I got this error:

Running migrations:
  No migrations to apply.
Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/Users/rostunov/temp/venv/lib/python2.7/site-packages/django/core/management/__init__.py", line 353, in execute_from_command_line
    utility.execute()
  File "/Users/rostunov/temp/venv/lib/python2.7/site-packages/django/core/management/__init__.py", line 345, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Users/rostunov/temp/venv/lib/python2.7/site-packages/django/core/management/base.py", line 348, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/Users/rostunov/temp/venv/lib/python2.7/site-packages/django/core/management/base.py", line 399, in execute
    output = self.handle(*args, **options)
  File "/Users/rostunov/temp/venv/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 183, in handle
    executor.loader.project_state(),
  File "/Users/rostunov/temp/venv/lib/python2.7/site-packages/django/db/migrations/loader.py", line 338, in project_state
    return self.graph.make_state(nodes=nodes, at_end=at_end, real_apps=list(self.unmigrated_apps))
  File "/Users/rostunov/temp/venv/lib/python2.7/site-packages/django/db/migrations/graph.py", line 280, in make_state
    project_state = self.nodes[node].mutate_state(project_state, preserve=False)
  File "/Users/rostunov/temp/venv/lib/python2.7/site-packages/django/db/migrations/migration.py", line 88, in mutate_state
    operation.state_forwards(self.app_label, new_state)
  File "/Users/rostunov/temp/venv/lib/python2.7/site-packages/django/db/migrations/operations/models.py", line 547, in state_forwards
    model_state = state.models[app_label, self.name_lower]
KeyError: ('list', u'user')

It happen after I pulled another version of my app from the git.

I don't have this error with the same code on the another machine. I've tried to use --fake with zero or to squashmigrations to previous but this also doesn't help.

Cannot get how to solve it.

Heroics

Don't try to fake or squash anything. This is a problem and you need to resolve it. Otherwise you are risking introducing database schema inconsistencies that will bite you in the ass later. First thing you want to try is to run python manage.py migrate -v 3 so you can see which individual migration causes the error. You might want to include the model being migrated and the migration code once you do that. – Zareba

Answer 1

The problem was in migration files. While I was making commit into git somehow I've deleted one of the migration files, so the order was like 0001 0003 0004 without 0002. In the second migration file I've created a model named user.

The problem was that when I run python manage.py migrate django could not find the place where the model named user has been created (this model has been created in 0002 file).

I solved it by manually adding this code to the 0001 migration file:

migrations.CreateModel(
        name='user',
        fields=[
            (...necessary fields...),
        ],
        options={
            'ordering': ('title',),
        },
    ),

Heroics

Answer 2

I ran into a similar issue, where db\migrations\operations\models.py was throwing a KeyError after renaming a model through PyCharm's refactoring (renaming).

Apparently the refactoring also took place in the migration file. When opening up the migration file and changing back to the original naming, the makemigrations command worked fine.

Ordinand

I have the same issue. And find the refactored class in migration file then rename it to orignal name solved my problem. – Dorcy

Anyone using an ide that isnt setup to ignore migrations files in refactors is most likely hitting this issue. Good catch! – Ur

Answer 3

I had the same issue and found that the easiest solution, if you models.py is intact, was just to delete all the old migrate files and then run makemigrations again. I don't think squashmigrations would help, since it only brings together all the different migration files into one, and it migrates on the basis of current migrate files. Which doesn't help if your migrate files are somehow corrupted. Which is what causes this issue in the first place.

Seism

very useful! Great solution! – Reindeer

Helped big time – Trattoria

I found a way to do it without nuking everything and putting your database put of sync. – Menstruation

Answer 4

I found what causes this and the solution for it. If you have a squashed migration that has a "replaces" property, remove the tuples in "replaces" that reference migrations missing from your django_migrations table. This fixes it.

Menstruation

Answer 5

I know it's an old question. But if any arrives googling:

In my particular case, I got that error after renaming a model and modifying its meta data at the same time (e. g. rename a model and its verbose name)

To fix it, I modified the last migration, removing (or commenting) the lines related to the meta data change, and run the migration command again. After that, run again makemigrations/migrate commands to update the meta data in the database

I'm using Django 2.0 and PostgreSQL 9.6

Hope you already fix it. JGED

Edit: PostgreSQL version

Greaser

Same issue: Django 2.2 and PostgreSQL 9.6. Since my migration never completed I simply deleted it and reverted my model changes. Then I made the name changes, migrated, and then updated the verbose names and migrate those. – Skyros

Cool. Django migrations are not "bullet proof". Great it worked for you @JoshuaHunter – Billyebilobate

Answer 6

I would make @ceasaro words, mine on his comment on this answer.

Newer versions of Django can detect changes and ask about what was done. I also would add that Django might mix the order of execution of some migration commands.

It would be wise to apply small changes and run makemigrations and migrate and if the error occurs the migration file can be edited.

Some lines order of execution can be changed to avoid the error.

Kandrakandy

Answer 7

If you don't care much about loss of history, you can go to the migrations directory of your app and delete all files there. then makemigrations and migrate. It won't cause loss of data but may cause problems later.

Montherlant

Answer 8

I ran into a similar problem, however, I could not identify the source of the problem in my migration files. Neither there was any missing migration files. It's possible I did not look hard enough.

However, when I 'squashmigrations' that fixed the problem. I am responding here just so anyone reaching this page can try this solution as well.

Sociability

Answer 9

Moving our project to python3 I had a similar issue which wasn't happening in python 2.7, when running using python3 this was my output:

Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/Users/silberringe/dms3/lib/python3.7/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line
    utility.execute()
  File "/Users/silberringe/dms3/lib/python3.7/site-packages/django/core/management/__init__.py", line 356, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Users/silberringe/dms3/lib/python3.7/site-packages/django/core/management/base.py", line 283, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/Users/silberringe/dms3/lib/python3.7/site-packages/django/core/management/base.py", line 330, in execute
    output = self.handle(*args, **options)
  File "/Users/silberringe/dms3/lib/python3.7/site-packages/django/core/management/commands/migrate.py", line 163, in handle
    pre_migrate_state = executor._create_project_state(with_applied_migrations=True)
  File "/Users/silberringe/dms3/lib/python3.7/site-packages/django/db/migrations/executor.py", line 81, in _create_project_state
    migration.mutate_state(state, preserve=False)
  File "/Users/silberringe/dms3/lib/python3.7/site-packages/django/db/migrations/migration.py", line 92, in mutate_state
    operation.state_forwards(self.app_label, new_state)
  File "/Users/silberringe/dms3/lib/python3.7/site-packages/django/db/migrations/operations/fields.py", line 201, in state_forwards
    state.models[app_label, self.model_name_lower].fields
KeyError: ('finder_app', 'listing')

As you can see I didn't even receive which file was causing the issue even using -v 3 even with the --fake it didn't work.

I eventually commented out and then uncommented each migration file in my finder_app until the error changed. At this point I know which file was causing the problem I had a squashed migration file named 0005_similarmake_squashed_0024_unspecified_color.py which squashed 0024 and 0005.

looking at the dependencies inside the file I saw that it was relying on 0004 and changed that to rely on 0024. and everything now works fine!

Danilodanio

Answer 10

Hey I got the same issue when I migrated the version from Django 1.11 to 3.2.4 to the latest version

on doing python manage.py migrate I was facing the same issue KeyError on doing migrate

I searched and found nothing on the internet so I tried to debug the root function in the module where the issue was coming lib/python3.8/site-packages/django/db/migrations/operations/fields.py", line 167, in state_forwards

this was the main function here I found on printing the self.name after doing migrate the self.name was coming in bytes so I found the b'code' in my entire migrations folder, Literally I found it there it was in bytes so made it to a string format and tried finally It worked for me !!!!!!!

Schoolbag

Answer 11

I am using Python3.9 with DJango 4.1.dev20211216191317.

How the problem occured for me:

I created my models, makemigrations, migrate, then wanted to change something. I am not worried about the loss of data, so I used psycopg2 to log into my postgres db, created the cursor, found the DB Tables that Django created and manually dropped them, committed (though I think you don't have to commit for table drops), and closed the connection. I then deleted the files in the migrations folder for my applet and tried making migrations after I had update my models.py. This caused the issue for me.

How I fixed it:

From what I can tell, because this was all that I did, after repeating the above several times with the same error, I held onto the latest migration file that was created (looks like 00001_init.py, or something of the sort), ran showmigrations and saw that Django recognized it in my applet, proceeded by migrate --fake my_applet zero. I think that I then deleted the migration file, followed by another makemigrations and migrate, which was able to successfully migrate.

Monophyletic