何时(如果)合并 ActiveRecord 迁移? [英] When (if) to consolidate ActiveRecord migrations?

问题描述

当我在我的应用程序上进行迭代时*(s) 我积累了迁移.截至目前，共有 48 个此类文件，活动时间约为 24 个月.

As I move through the iterations on my application*(s) I accumulate migrations. As of just now there are 48 such files, spanning about 24 months' activity.

我正在考虑采用我当前的 schema.rb 并将其作为基线.

I'm considering taking my current schema.rb and making that the baseline.

我也在考虑删除(当然，受源代码控制)现有迁移并从我当前的架构创建一个漂亮的闪亮的新单一迁移?迁移倾向于喜欢符号，但 rake db:schema:dump 使用字符串:我应该关心吗?

I'm also considering deleting (subject to source control, of course) the existing migrations and creating a nice shiny new single migration from my my current schema? Migrations tend to like symbols, but rake db:schema:dump uses strings: should I care?

这看起来合理吗?如果是这样，这样的练习在什么样的时间间隔才有意义?如果没有，为什么不呢?

Does that seem sensible? If so, at what sort of interval would such an exercise make sense? If not, why not?

我是否错过了一些可以为我做这件事的(耙子?)任务?

And am I missing some (rake?) task that would do this for me?

* 就我而言，所有应用程序都是基于 Rails 的，但任何使用 ActiveRecord 迁移的东西似乎都适合这个问题.

* In my case, all apps are Rails-based, but anything that uses ActiveRecord migrations would seem to fit the question.

推荐答案

是的，这是有道理的.有一种合并迁移的做法.为此，只需将当前架构复制到迁移中，然后删除所有早期迁移.这样您就可以管理更少的文件，并且测试可以运行得更快.您需要小心执行此操作，尤其是当您在生产环境中自动运行迁移时.我通常用新模式替换我知道每个人都运行过的迁移.

Yes, this makes sense. There is a practice of consolidating migrations. To do this, simply copy the current schema into a migration, and delete all the earlier migrations. Then you have fewer files to manage, and the tests can run faster. You need to be careful doing this, especially if you have migrations running automatically on production. I generally replace a migration that I know everyone has run with the new schema one.

其他人的做法略有不同.

Other people have slightly different ways to do this.

在我们进行超过 100 次迁移之前，我通常不会这样做，但我们可以在几个月的开发后实现这一目标.但是，随着项目的成熟，迁移的频率越来越低，因此您可能不必再做一次.

I generally haven't done this until we had over 100 migrations, but we can hit this after a few months of development. As the project matures, though, migrations come less and less often, so you may not have to do it again.

这确实违反了最佳做法:一旦您签入到源代码管理的迁移，就不要更改它.如果其中有一个错误，我会做一个罕见的例外，但这非常罕见(可能是 100 个中的 1 个).原因是一旦它们在野外出现，有些人可能已经运行它们了.它们被记录为在数据库中完成.如果您更改它们并签入新版本，其他人将无法从更改中受益.您可以要求人们回滚某些更改并重新运行它们，但这违背了自动化的目的.经常做，就会变得一团糟.最好不要管.

This does go against a best practice: Once you check in a migration to source control, don't alter it. I make a rare exception if there is a bug in one, but this is quite rare (1 in 100 maybe). The reason is that once they are out in the wild, some people may have run them. They are recorded as being completed in the db. If you change them and check in a new version, other people will not get the benefit of the change. You can ask people to roll back certain changes, and re-run them, but that defeats the purpose of the automation. Done often, it becomes a mess. It's better left alone.

这篇关于何时(如果)合并 ActiveRecord 迁移?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！