Django数据库迁移失败求助：字段修改后问题无法解决

Hey there, let's figure out why you're stuck with this migration error even after rolling back your field change and messing with the database. Here's what's going on and how to fix it step by step:

核心原因：迁移历史的冲突残留 #

The main issue here is that Django's migration system keeps a record of every change you make—even when you revert a field from ForeignKey back to ManyToMany. Restarting Postgres or deleting tables only fixes the database side, but the messed-up migration history in your project files and the django_migrations database table is still causing a mismatch.

分步解决指南 #

1. 先摸清当前迁移状态 #

First, run this command to see which migrations have been applied and which are pending for your rango app:

python manage.py showmigrations rango

You'll probably see some weird entries or mismatches between local files and what's marked as applied in the database.

2. 清理旧的迁移记录（先备份！） #

• Make a backup of all files in rango/migrations/ except __init__.py—you never know when you might need them.
• Delete all those migration files (leave __init__.py alone).
• Next, connect to your Postgres database and clear out the migration records for the rango app. Run this SQL query:

  DELETE FROM django_migrations WHERE app = 'rango';
  

  You can do this via psql command line, or use Django's shell if you prefer.

3. 重新生成干净的初始迁移 #

Go back to your project root and generate a fresh migration that matches your current model structure:

python manage.py makemigrations rango

This will create a new set of migrations that accurately reflect your ManyToManyField setup.

4. 应用迁移到数据库 #

Now apply the new migrations. If you get an error about tables already existing, use the --fake-initial flag to tell Django to skip creating tables it thinks are already there:

python manage.py migrate rango --fake-initial

This should sync the migration history with your actual database structure.

5. 最后检查细节 #

• Double-check your model file: Make sure the ManyToManyField is defined correctly, with no leftover on_delete parameters (since ManyToMany doesn't require that, unlike ForeignKey).
• If you had any related_name or other custom parameters on the original ManyToManyField, make sure they're included now.

为什么之前的操作没起效？ #

Restarting Postgres or deleting tables only resets the database itself, but Django relies on the django_migrations table to track which changes have been applied. When you flipped between ForeignKey and ManyToMany, you created conflicting migration records that weren't fixed by just resetting the database—you needed to wipe the migration history and start fresh.

内容的提问来源于stack exchange，提问作者FANCY_HOOMAN