升级Django与django-cms时遭遇数据库迁移错误求助

你之前的操作其实走进了一个典型的迁移误区：删除CMS迁移文件+清空django_migrations表再用--fake，相当于告诉Django「所有CMS迁移都已经执行完毕」，但实际上新版本需要的新表（比如cms_urlconfrevision）根本没创建；而直接跑migrate的话，旧版本已经存在的表又会让迁移脚本报错「表已存在」。下面是针对性的修复步骤：

步骤1：优先恢复旧迁移记录（如果有备份的话） #

如果你在操作前备份过数据库，先恢复django_migrations表中所有app='cms'的记录——这能让Django准确识别哪些旧版本的迁移已经执行过，是最稳妥的起点。如果没有备份，继续往下看。

步骤2：标记旧表对应的初始迁移为已执行 #

运行这条命令，让Django跳过创建旧表的迁移（因为这些表已经存在），但不会影响后续需要创建新表的迁移：

python manage.py migrate cms --fake-initial

步骤3：执行剩余迁移创建新表 #

接下来正常执行CMS的迁移，这时候Django只会处理那些还没标记为完成的迁移，也就是创建新版本需要的cms_urlconfrevision等新表，不会触碰已存在的旧表：

python manage.py migrate cms

步骤4：处理个别剩余的表冲突（如果有的话） #

如果还是出现「某表已存在」的报错，找到对应的迁移文件名（比如报错信息里提到的0001_initial），单独标记这个迁移为已执行：

python manage.py migrate cms 0001 --fake

完成后再重新执行python manage.py migrate cms，继续完成剩下的迁移。

步骤5：验证迁移状态 #

运行这条命令查看所有CMS迁移的状态，确保所有条目都显示[X]（表示已完成）：

python manage.py showmigrations cms

之后启动应用，检查cms_urlconfrevision不存在的错误是否消失。

额外提醒 #

• 操作前一定要备份数据库：迁移操作很容易破坏数据，备份是底线。
• 不要随便删除第三方库的迁移文件：Django CMS的迁移是官方维护的，删除后很容易出现版本不匹配问题。
• 跨大版本升级建议分步来：从2.4直接跳到3.5跨度太大，中间可以先升到3.0，再逐步升到3.5，能减少很多奇怪的兼容性问题。

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