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.
Answers:
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',),
},
),
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.
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.
I ran into a similar issue, where dbmigrationsoperationsmodels.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.
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.
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.
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
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!
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.
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 !!!!!!!
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.
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.
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',),
},
),
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.
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.
I ran into a similar issue, where dbmigrationsoperationsmodels.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.
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.
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.
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
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!
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.
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 !!!!!!!
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.