我的数据库（postgresql）中有一个表，该表与我的Django应用程序中的model feedback相关联（也称为feedback）。< / p>
我在feedback文件中删除了models.py模型的几列，然后使用以下命令创建了迁移：
python manage.py makemigrations feedback
然后尝试＆＃34;合并＆＃34;它与我的数据库使用：
python manage.py migrate feedback
但是我得到了错误：
django.db.utils.ProgrammingError: relation "feedback" already exists
当然它存在，但我想应用我所做的改变。在migrations文件夹中，我有以下文件：
__init__.py
0001_initial.py
0002_remove_feedback_created_on.py
0003_remove_feedback_is_read.py
最后一个包含我最近的更改。我该怎么办？
答案 0 :(得分：1)
通常，当您在数据库中的某个位置应用更改时会出现此relation x already exists问题，但Django迁移系统并未了解您已经这样做的事实。怎么会发生？例如，如果您向模型添加ForeignKey字段，请进行迁移，迁移它，然后改变主意并删除迁移，而不会在此之前向后迁移。项目中没有任何中断，但数据库中的关系和字段仍然存在（如果字段不可为空，则可能会遇到麻烦）。现在，如果你再次改变主意并决定shiiit，我需要该字段，然后重新添加，进行新的迁移并尝试迁移它，然后出现relation x already exists错误。
好的，那么呢？通常最简单的方法是伪造失败的迁移，但 BEWARE 如果迁移中有任何其他未应用的更改，则这些更改也不会应用于数据库。在开始伪造迁移之前，请确保您了解伪造的内容和原因。理想情况下，迁移文件中只有一个AddField即将被伪造，因为否则迁移文件中的所有更改都将被伪造（伪造迁移意味着更改不会应用于数据库，而是Django会考虑他们完成）。
如果您有两个未应用的迁移，那么您绝对不应在未指定迁移编号的情况下运行migrate --fake，因为后一个未应用的迁移也将不会应用。在你的情况下看来，之后运行manage.py migrate 0002 --fake和manage.py migrate可能会解决所有问题，但如果不知道你所做的一切，就不可能肯定地说。
如果我拿起你的项目，这就是我要做的事情：
1）检查0002是否包含多个更改
如果是，则将除失败字段之外的所有内容复制到0003
如果不是，请继续manage.py migrate 0002 --fake
2）再次运行manage.py migrate以迁移0003。
答案 1 :(得分：0)
它也可以帮助迁移。
python3 manage.py migrate --run-syncdb