开发的时候总会修修改改
然后就看到 migrate 文件一直叠加生成
问题是开发的时候 DB 结构可能被我改来改去 过一会甚至还会有回退的 migrate 文件(
然后强迫症就很不爽 我会在确认修改后把本地数据库整个清掉 然后 git reset 掉所有开发期间的 migrate 文件
再重新生成一遍 migrate 再同步到生产库去
这是正常开发流程吗 怎么感觉一点都不优雅
开发的时候总会修修改改
然后就看到 migrate 文件一直叠加生成
问题是开发的时候 DB 结构可能被我改来改去 过一会甚至还会有回退的 migrate 文件(
然后强迫症就很不爽 我会在确认修改后把本地数据库整个清掉 然后 git reset 掉所有开发期间的 migrate 文件
再重新生成一遍 migrate 再同步到生产库去
这是正常开发流程吗 怎么感觉一点都不优雅
|
1
是正常流程,不优雅的是你将数据库改来改去,而你也在最后通过自己的手段压缩了变更,别人看起来就挺优雅的了。
不过这个流程挺容易出事故的,轻则发布失败,重则数据丢失,多人合作很难要求别人整理 migrations 。 |
|
2
有些语言框架你还得手动写 migration 呢。。比如写 go 的时候用 sqlc
|
|
3
db 修改我都是手写 sql ,原来还有自动的……
|
|
4
@Vegetable #1 啊啊啊啊啊 主要是很难受
就开发的时候 自己改着改着 就看到 0004 、0005 、0006 、0007 其中 0006 可能是撤销 0004 的 然后本地如果提交上去我就会看着很不爽 所以手动删掉从本地的 0004-0007 再重新生成一遍 0004 往生产去交 我还以为有更好的方案 可以自动帮我完成 git 和 migrate 的合体( |
|
5
不用 Django, 但是用 Rails.
许多公司的 devops 流程是表结构在「开发设计评审」阶段就确认, 后续修改都要和 code review 的同事对齐. 即便是开发阶段也是不能随便修改. 自己的项目那就随便拉, 只要能跑起来就无所谓. 只有带着镣铐跳舞才能优雅, 这就是为啥公司会有一堆条条框框, 你把镣铐解除了那自然优雅不了辣... 说起来, njit 前辈? |
|
8
多人开发 django 项目,migrations 文件夹不提交 git ,每次合并到 master 的时候,重新生成 migrations 文件
|
|
9
@Licsber #4 我就是这样处理的,但是我是按照需求来进行的,比如一个需求产生了 0004 0005 0006 我就三合一再提交,要注意的几个点,一得默认值什么的检查仔细点,二是记得同步 django_migrations 那张表
|
|
10
奇怪的强迫症。模型字段不仔细思考就改,是你这个问题的根源。
|
|
11
上线前我也会这样,上线后就只正经用 migration 来改数据库了。
|
|
12
这也是我一开始碰到的疑问。。后来一看,就 3-4 个人。。我脑子有包有个变更就+1 版本。直接 new 一个版本,在这个版本上改对为止。一次迭代有且只有一个版本
|
|
13
开发时 不用那么每次改数据库都要搞一个版本 怎么方便怎么来
确保提交时的 migration 没问题就行 |
|
14
|
|
16
测试环境开发完了,把生成的 migrate 文件全删了重新生成,这样只会有一个 migrate 文件,这个不是基操了吗?
|