我跑python manage.py makemigrations
然后我得到:
未检测到任何更改
然后,python manage.py migrate
我得到:
无需迁移。
然后,我尝试将更改推送到生产中: git push heroku master 一切都是最新的
然后,在生产中,我重复命令: heroku运行python manage.py migrate 无需迁移。
以防万一,我在生产中运行makemigrations
:
heroku run python manage.py makemigrations
No changes detected
为什么我得到了
ProgrammingError at ....
column .... does not exist
“未检测到任何更改”表示数据库与代码一致。 我该怎么调试呢?
答案 0 :(得分:10)
我遇到了同样的问题(列不存在),但是当我尝试migrate
而不是makemigrations
时(我认为这是同一个问题)
原因:我删除了迁移文件,并在运行上次更改的迁移之前将其替换为单个假装初始迁移文件0001
解决方案:
django_migrations
中删除负责该应用程序迁移的行,这就是Django如何知道哪些迁移已应用以及哪些仍需要应用。以下是解决这个问题的方法:
以postgres用户身份登录(我的用户名为posgres):
sudo -i -u postgres
打开一个sql终端并连接到您的数据库:
psql -d database_name
列出您的表并找出与该应用相关的表格:
\dt
放弃它们(考虑关系下降顺序):
DROP TABLE tablename ;
id | app |名字|应用
- + ------ + -------- + --------- +
SELECT * FROM django_migrations;
删除该应用的迁移行(您可以按ID或应用删除,应用不要忘记'引号'):
DELETE FROM django_migrations WHERE app='yourapp';
仅注销并运行您的迁移(可能在您的情况下运行makemigrations):
python manage.py migrate --settings=your.settings.module_if_any
注意:在您的情况下,可能不必删除该应用程序的所有表,也不必删除所有迁移,只有那些导致问题的模型。
我希望这可以提供帮助。
答案 1 :(得分:6)
Django迁移记录在'django_migrations'表下的数据库中。这就是Django如何知道哪些迁移已经应用以及哪些仍然需要应用。
查看数据库中的django_migrations表。应用迁移时可能出现问题。因此,删除表中具有与该列“不存在”相关的迁移文件名的行。然后,尝试重新运行迁移。
答案 2 :(得分:4)
这是我尝试过的方法,并且有效:
答案 3 :(得分:1)
我遇到了类似的问题 - 当我点击django-admin网站上的模型时出现错误消息。我通过在models.py中注释掉字段然后运行迁移来解决它。在此之后,我取消了该字段的注释并重新进行了迁移。之后,错误消息消失了。
答案 4 :(得分:1)
问题出在我身上,出于某种原因,Django在我的外键列的末尾添加了“ _id”。我必须明确将相关的名称设置为外键。这里的“卡片”是父表,“价格”是子表。
class Cards(models.Model):
unique_id = models.CharField(primary_key=True, max_length=45)
name = models.CharField(max_length=225)
class Prices(models.Model):
unique_id = models.ForeignKey(Cards, models.DO_NOTHING)
更改为:
class Cards(models.Model):
unique_id = models.CharField(primary_key=True, max_length=45)
name = models.CharField(max_length=225)
class Prices(models.Model):
unique_id = models.ForeignKey(Cards, models.DO_NOTHING, db_column='unique_id')
答案 5 :(得分:0)
所以,我总是遇到这种问题,所以今天我决定尝试在数据库级别上解决它。问题是,我更改了Django
并没有反映在迁移文件中的模型字段名称。我后来才发现问题时才发现。后来我查看了迁移文件,发现该更改没有迁移。但是我没有注意到,因为我也进行了其他更改,所以一旦看到迁移文件,我就会很高兴。
我的建议。一次为每个变更创建迁移。这样,您就可以查看它是否发生过。
这是我在MySQL中进行的工作。
打开mysql控制台。
show databases; # see all my dbs. I deleted a few
drop database <db-name>; # if needed
use <db-name>; # the database name for your django project
show tables; # see all tables in the database
DESCRIBE <table-name>; # shows columns in the database
SHOW COLUMNS FROM <db-name>; # same thing as above
ALTER TABLE <table-name> CHANGE <old-column-name> <new-column-name> <col-type>; # now I manually updated my column name
如果您使用的是Postgresql,只需在Google上搜索相应的命令即可。
答案 6 :(得分:0)
我的案子可能有点晦涩难懂,但是如果对某人有帮助,就可以在这里进行记录。
我在一次迁移中调用了一个函数,该函数会定期(即)导入所述迁移的模型。
from myApp.models import ModelX
在迁移中导入模型的唯一方法是使用例如RunPython:
def myFunc(apps, schema_editor):
MyModel = apps.get_model('myApp 'MyModel')
然后像这样调用该函数:
class Migration(migrations.Migration):
operations = [
migrations.RunPython(initialize_mhs, reverse_code=migrations.RunPython.noop),
]
另外,原始导入一直有效,直到我在以后的迁移中修改模型为止,这使此错误更难定位。
答案 7 :(得分:0)
只需在数据库的“ django_migrations”模型中删除该模型的相应行迁移即可。
然后重新运行python manage.py migrate app_name
答案 8 :(得分:0)
我尝试了所有这些答案,但运气不佳!我所做的没有任何伤害地解决了这个问题是返回通过迁移文件并找到第一次创建实际模型的位置然后手动添加字段(在列中不存在错误消息)。直到您运行 you need R upgraded as dplyr is built in R 3.6.3
时,您才会看到/看到“未检测到更改”并且有效。基本上,就我而言,我必须在适当的迁移文件中及时将所需的数据库更改小心地取回,而不是在迁移依赖链的末尾创建一个新的迁移。
答案 9 :(得分:-1)
通过运行解决了这个问题 python manage.py 迁移 在 Heroku Bash shell 中