我正在开发的Rails应用程序到目前为止已有约35个迁移。由于该应用程序最初是作为一个实验开始的，因此在我反复尝试不同的想法时存在相当多的无意义的变动。
将迁移1-35合并成一个迁移是否有任何缺点？我计划通过第一个迁移加载当前模式并删除所有先前的迁移来完成这个步骤。
如果只有我自己在这个项目上工作，那是否有所不同？
6个回答
11
如果您的代码已经在源代码控制下（您确实将代码放在了源代码控制下，不是吗？）那么我认为没有什么实质性的伤害，只要您接受回滚模式更改需要恢复旧的迁移或创建全新的迁移的事实。在最终确定前确保您理解这些影响并接受它们。
您当前的schema.rb可以成为启动新集合的新单个迁移的基础。
请注意，如果您的现有迁移中包含数据操作，例如静态数据加载和/或可能的后续转换，则这些操作需要在某处处理。这是我遇到过几次的问题...
- Mike Woodhouse
6
我会将它们保留。不用担心每次新开发者检出项目时需要运行大量迁移。他始终可以运行。
rake db:schema:load
使用更快速的方法代替运行
rake db:migrate
- erik
5
有时迁移可能会使用不存在的模型或创建表，然后再销毁它们，浪费了宝贵的CPU时间。最好将所有内容编译到db/schema.rb中，并让开发人员运行
rake db:schema:load。- Radar
2
如果你的所有迁移只是修改你的表结构，那么你不用担心。但要记住，有些迁移会添加数据——我有一些迁移，可以为数据库提供管理员帐户和其他固定数据——而仅仅使用架构是无法实现这一点的。
不过，我所做的迁移方式并不好，因为我在部署时并没有使用迁移。因此，将数据填充迁移移到单独的rake任务中可能是个好主意。
经过审查，我重申了已经提出的观点。
不过，我所做的迁移方式并不好，因为我在部署时并没有使用迁移。因此，将数据填充迁移移到单独的rake任务中可能是个好主意。
经过审查，我重申了已经提出的观点。
rake db:migrate VERSION -1
[我把注意力从文本上转移开来，归咎于分散注意力的新动画标志]- srboisvert
1
没有任何害处，合并迁移是一个好的实践方法，并且在需要运行迁移时有助于提高性能。这现在已经成为Rails的schema.rb的一部分：
# Note that this schema.rb definition is the authoritative source for your
# database schema. If you need to create the application database on another
# system, you should be using db:schema:load, not running all the migrations
# from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
注意，正如 @mike-woodhouse 所说，“请注意，如果您的现有迁移中存在数据操作，例如静态数据加载和/或可能的后续转换，则这些操作需要在某个地方处理。”
但是你不应该在迁移中做任何这样的操作 :) -- Chad
- thewoolleyman
-1
对于那些像我一样通过搜索找到这个答案来寻找将应用程序重置回其原始状态的方法的人，以下是要做的事情：
rm db/migrations/*
rake db:drop
rake db:schmea:dump
如果你刚开始开发一个应用程序，决定重新开始建立，而不想丢失所有的文件，这将非常有用。
- Dana Woodman
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接