我有一个django应用程序,直到现在我使用sqLite作为数据库后端。现在,当它非常接近生产时,我想把它全部移到mySQL上,它将被用在盒子上。
我将设置重新配置为mysql数据库并运行
manage.py syncdb --migrate
它开始创建表格,但在第一次(全部40个)迁移中失败并且出现旧错误(can't insert blob without key length以及所有这些)。
我首先考虑手动修复迁移文件,但很快意识到手动工作太多了。
所以我认为没问题我将运行manage.py migrate core 0040(最后一次迁移,这将有所帮助)但它仍然尝试运行初始的:
File "D:\~Sasha\Portman\core\migrations\0001_initial.py", line 23, in forwards
('name', self.gf('django.db.models.fields.TextField')(unique=True)),
... error message
有没有办法以某种方式迁移我的模型而无需手动修复初始迁移文件和所有其他魔法?
答案 0 :(得分:5)
首先,您无法选择要运行的迁移。 migrate core 0040
表示将所有迁移运行到 0040.换句话说,它不会运行0041,但将运行0001-0040。
现在,它稍微提出了你的问题,但是如果你还没有将这个项目转移到生产中,那么你实际上并不需要所有这些迁移。假设它们都是schemamigrations,您可以使用以下命令回滚到零:
python manage.py migrate core zero
然后,将它们全部删除(包括0001_initial.py),然后再次运行:
python manage.py schemamigration --initial core
重新生成初始迁移。它将基于模型的当前状态,无需进行40次迁移。
在将新代码转移到生产环境之前,最好先压缩这样的迁移。由于这是第一次启动,您可以将它们全部删除并从头开始,但在将来的迭代中,如果您在开发过程中生成5次迁移,在提交之前,回滚到第一次之前,则删除那些5和然后生成一个新的schemamigration。结果只是一次迁移,其中包含那些5的所有更改。然后,您可以提交并在生产中迁移。
这可能无法完全解决您的问题,但它肯定会使调试更简单。
答案 1 :(得分:2)
我偶尔会在mysql后端部署项目时遇到迁移问题。
由于您正在部署新副本,因此您可以选择几种方法来回避运行所有强制的需求:
首先,如果您希望按原样维护迁移历史记录,则无论迁移如何,都可以强制syncdb创建所有表,然后运行虚假迁移以使新数据库保持最新状态。那看起来像是:
python manage.py syncdb --all
python manage.py migrate --fake
或者,如果您不关心历史迁移,则可以清除旧迁移(只删除它们),然后创建新的初始迁移,例如:
python manage.py schemamigration --initial core
请确保您还清除了dev数据库中的south_migrationhistory
表,以便dev和prod之间的所有内容保持同步