postgresql Django + posgtres 关系不存在错误
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/36087664/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Django + posgtres relation does not exist error
提问by Nick
I understand how many questions there are for this matter but none of the solutions suggested helped.
I got the following problem:
I deleted my models and deleted the imports in admin.py
as well. Then I wanted to update the django database with makemigrations
which shows that it deletes the model employee but then after using migrate
command I saw an error that the relation does not exist. I also dropped it from the postgres database that I used.
The strange thing here is that migrate keeps looking for the model which does not exists. Even if I create another one makemigrations
detects it and then migrate
says relation project_employee..
Tried syncdb --all
no success. here is the output of migrate
我知道这件事有多少问题,但建议的解决方案都没有帮助。我遇到了以下问题:我删除了我的模型并删除了导入admin.py
。然后我想更新 django 数据库,makemigrations
它显示它删除了模型员工,但在使用migrate
命令后我看到了一个错误,即关系不存在。我也从我使用的 postgres 数据库中删除了它。这里奇怪的是 migrate 一直在寻找不存在的模型。即使我创建另一个makemigrations
检测到它然后migrate
说relation project_employee..
尝试syncdb --all
没有成功。这是输出migrate
Apply all migrations: sessions, project, admin, auth, contenttypes
Running migrations:
Applying project.0003_auto_20160318_1215...Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 65, in execute
return self.cursor.execute(sql, params)
psycopg2.ProgrammingError: relation "project_employee" does not exist
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
utility.execute()
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 377, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 338, in execute
output = self.handle(*args, **options)
File "/usr/lib/python3/dist-packages/django/core/management/commands/migrate.py", line 161, in handle
executor.migrate(targets, plan, fake=options.get("fake", False))
File "/usr/lib/python3/dist-packages/django/db/migrations/executor.py", line 68, in migrate
self.apply_migration(migration, fake=fake)
File "/usr/lib/python3/dist-packages/django/db/migrations/executor.py", line 102, in apply_migration
migration.apply(project_state, schema_editor)
File "/usr/lib/python3/dist-packages/django/db/migrations/migration.py", line 108, in apply
operation.database_forwards(self.app_label, schema_editor, project_state, new_state)
File "/usr/lib/python3/dist-packages/django/db/migrations/operations/fields.py", line 84, in database_forwards
schema_editor.remove_field(from_model, from_model._meta.get_field_by_name(self.name)[0])
File "/usr/lib/python3/dist-packages/django/db/backends/schema.py", line 431, in remove_field
self.execute(sql)
File "/usr/lib/python3/dist-packages/django/db/backends/schema.py", line 111, in execute
cursor.execute(sql, params)
File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 81, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 65, in execute
return self.cursor.execute(sql, params)
File "/usr/lib/python3/dist-packages/django/db/utils.py", line 94, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/usr/lib/python3/dist-packages/django/utils/six.py", line 658, in reraise
raise value.with_traceback(tb)
File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 65, in execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: relation "project_employee" does not exist
`
`
Thank you
谢谢
采纳答案by Nick
What helped finally was deleting the whole migrations folder from the project's folder. Saw some south responses as well, but haven't tried.
最终有帮助的是从项目文件夹中删除整个迁移文件夹。也看到了一些南方的回应,但没有尝试过。
回答by Leonard2
AFAIK, you should not directly delete a table from the DB before the migration. If you change your model, then manage.py migrate
will do the thing.
AFAIK,您不应该在迁移之前直接从数据库中删除表。如果你改变你的模型,那么manage.py migrate
就会做这件事。
django cannot detect the direct change of DB; only knows the change of model script. Therefore if you drop a table, then django does not detect the change, so django keeps looking for the table which was dropped and gives the error.
django 无法检测到 DB 的直接变化;只知道模型脚本的变化。因此,如果您删除一个表,则 django 不会检测到更改,因此 django 会不断查找被删除的表并给出错误。
Sometimes migration does not work for no reasons. in that case, I do the following things:
有时迁移无缘无故不起作用。在这种情况下,我会做以下事情:
- undo the change of models.py
- do the django migration (
manage.py makemigrations appname
works better thanmanage.py makemigrations
) - if the migration works, then change the models.py again
- do the django migration again
- 撤消models.py的更改
- 做 django 迁移(
manage.py makemigrations appname
比 更好用manage.py makemigrations
) - 如果迁移有效,则再次更改models.py
- 再次进行 Django 迁移
this works sometimes.
这有时有效。
回答by Shinto Joseph
Drop the tables in the db using the below code
使用以下代码删除数据库中的表
python manage.py migrate app_name zero
Then again migrate
然后再次迁移
python manage.py migrate app_name
The reason is that there is already a table present, and when you do a "initial migration",Django will see that the initial migration has already been applied since the table is already present with old schema and therefore not taking the new table with different schema into consideration.
原因是已经存在一个表,当你进行“初始迁移”时,Django 会看到初始迁移已经被应用,因为该表已经存在旧模式,因此不会采用不同的新表模式考虑在内。
回答by Jamal Al-kelani
I was able to solve this issue by the following steps
我能够通过以下步骤解决这个问题
when I was running this command
python manage.py migrate app_name zero
it was complaining about that some table is missing. so I've created a dummy table with a dummy column.
I've run the command again
python manage.py migrate app_name zero
I've applied the migrations for that app
python manage.py migrate app_name
当我运行这个命令时
python manage.py migrate app_name zero
它抱怨缺少一些桌子。所以我创建了一个带有虚拟列的虚拟表。
我再次运行命令
python manage.py migrate app_name zero
我已经为该应用程序应用了迁移
python manage.py migrate app_name
回答by Will
All I needed to do was to create a table with the same name and one dummy column. Then when I migrated, django remade all of the columns for me.
我需要做的就是创建一个具有相同名称和一个虚拟列的表。然后当我迁移时,django 为我重新制作了所有的列。