django migration 的问题

查看 99|回复 8
作者:guoguobaba   
测试环境是 sqlite , 随时都可以 makemigrations ; migrate ,而且修改 model 后都能生效
生产环境用的是 mysql makemigrations 和 migrate 没反应,看网上的文章,清掉
django-migration 这个表,那些没有修改过的表会报告 exists 从而退出。用
--fake-initial ,修改后的表又不能生效。最后只能备份,删除,重新 migrate 。

migrate, 修改, 生效, 表会

misoomang   
首先 python3 manage.py makemigrations 是会基于 django_migration 表和当前的 model.py 进行的差异对比生成 migrations 文件,执行 migrate 后是根据新增的 migrations 文件执行表结构变更后在 django_migrations 插入对应 migrations 文件对应的 app 信息和时间戳版本信息
所以需要对比 django_migrations 表各 app 执行模块对应最新版本信息、migrations 文件信息、以及对应表结构综合对比
encro   
没有反应,总有错误提示吧,没有错误提示?
ZX576   
与题目无关,生产环境不建议用 migrate ,使用 sql 文件管理,一次次更新做好版本控制,表结构的变更需要多个人过目,这样不容易出大锅
Hstar   
先不说 migration 为什么带到生产环境用的问题,生产环境为什么要 makemigrations ,直接把测试环境生产的 migrations 文件跑一遍 migratei 就好了呀。
Hstar   
最佳实践是非生产环境用 django migration 工具,同时 migrations 文件要和 models 文件一起提交到 git ,各种调试和反复确定 model 后合并一下 migrations 问卷只留下个位数的,然后用 sql migratie 命令得到这些 migrations 文件的实际执行 sql ,然后再生产执行这些 sql
djangovcps   
migrations 可以提交到仓库里,线上直接执行 migrate 一般没问题,但是你中间有一次断档了,就有点麻烦了
djangovcps   
建议将此次改动先 执行 show sqlmigrate 返回 sql ,生产直接跑 sql ,然后对每个改过的 app 执行 fake 迁移, 然后将测试环境迁移表同步到生产,并将 migrations 文件提交到 git ,下次直接 migrate 就可以了
allisone   
之前也遇到过这样的问题,后面直接再弄一个分支专门用来做 Malians 保证迁移文件干净整洁
您需要登录后才可以回帖 登录 | 立即注册

返回顶部