django migration 的问题

测试环境是 sqlite ，随时都可以 makemigrations ； migrate ，而且修改 model 后都能生效

生产环境用的是 mysql makemigrations 和 migrate 没反应，看网上的文章，清掉
django-migration 这个表，那些没有修改过的表会报告 exists 从而退出。用
--fake-initial ，修改后的表又不能生效。最后只能备份，删除，重新 migrate 。

migrate

修改

生效

表会

15 条回复 • 2023-12-16 14:34:45 +08:00

misoomang

2023-12-13 16:27:20 +08:00

首先 python3 manage.py makemigrations 是会基于 django_migration 表和当前的 model.py 进行的差异对比生成 migrations 文件，执行 migrate 后是根据新增的 migrations 文件执行表结构变更后在 django_migrations 插入对应 migrations 文件对应的 app 信息和时间戳版本信息

所以需要对比 django_migrations 表各 app 执行模块对应最新版本信息、migrations 文件信息、以及对应表结构综合对比

encro

2023-12-13 17:18:43 +08:00

没有反应，总有错误提示吧，没有错误提示？

ZX576

2023-12-13 18:07:41 +08:00

与题目无关，生产环境不建议用 migrate ，使用 sql 文件管理，一次次更新做好版本控制，表结构的变更需要多个人过目，这样不容易出大锅

Hstar

2023-12-13 18:27:01 +08:00

先不说 migration 为什么带到生产环境用的问题，生产环境为什么要 makemigrations ，直接把测试环境生产的 migrations 文件跑一遍 migratei 就好了呀。

Hstar

2023-12-13 18:30:18 +08:00

最佳实践是非生产环境用 django migration 工具，同时 migrations 文件要和 models 文件一起提交到 git ，各种调试和反复确定 model 后合并一下 migrations 问卷只留下个位数的，然后用 sql migratie 命令得到这些 migrations 文件的实际执行 sql ，然后再生产执行这些 sql

djangovcps

2023-12-13 18:32:50 +08:00

migrations 可以提交到仓库里，线上直接执行 migrate 一般没问题，但是你中间有一次断档了，就有点麻烦了

djangovcps

2023-12-13 18:34:34 +08:00

建议将此次改动先执行 show sqlmigrate 返回 sql ，生产直接跑 sql ，然后对每个改过的 app 执行 fake 迁移，然后将测试环境迁移表同步到生产，并将 migrations 文件提交到 git ，下次直接 migrate 就可以了

allisone

2023-12-13 18:54:57 +08:00 via iPhone

之前也遇到过这样的问题，后面直接再弄一个分支专门用来做 Malians 保证迁移文件干净整洁

devliu1

2023-12-13 20:01:01 +08:00

prod 用 migration 没问题，问题是 migration 必须只增不减，必须每次进 repo ，不要动 migration 表。

chonerlee

2023-12-13 20:08:42 +08:00

makemigration 生成的 migration 文件提交到 repo 了吗？

guoguobaba

2023-12-13 23:54:08 +08:00

```
# sed -i 's/256/255/g' home_application/models.py
# python manage.py makemigrations
No changes detected
```

看来是这个原因

founddev

2023-12-14 15:36:17 +08:00

在 django 中正确的操作是：
1 、开发环境随意 makemigration 和 migrate ，需要注意的是每次 makemigration 如果 Model 有变动都会生成一个迁移文件在 migrations 里。
3 、git 提交代码前，还要删除所有新增的 migrations 里的文件，重新 makemigration 生成迁移文件，并使用 migrate --fake ，原因是这样操作会把多个生成的多个迁移文件变成一个，使用--fake 是因为数据库已经更改，并不需要重新更改数据库结构，只会把迁移记录加到数据库里。
4 、版本控制 migrations 文件夹里的文件
5 、正式环境，只做两件事 git pull 和 migrate

founddev

2023-12-14 15:39:52 +08:00

建议了解一下 django 迁移文件的原理，并用数据库工具查看一下 django_migrations 这张表，看一下里面有什么，了解 makemigration 、migrate 干了什么，以及--fake 的作用是什么。有能力建议看一下源码。

guoguobaba

2023-12-15 13:40:00 +08:00

@founddev 你说的问题我都做过，实际上问题出现在 makemigrations 里不会体现 models 的变更。目前还不清楚原因。

encro

2023-12-16 14:34:45 +08:00

前面有人提到了。就是 makemigrations 只在本地干一次，检查生成的 sql ，本地运行 migration 。线上只运行 migrate ，千万不要线上 makemigrations ，那导致你 migrations 文件错乱，同理，也不要直接去改本地或者线上数据库结构。