清除旧的Rails迁移文件是一个好主意吗?

I have been running a big Rails application for over 2 years and, day by day, my ActiveRecord migration folder has been growing up to over 150 files.

我已经运行一个大型Rails应用程序两年多了，我的ActiveRecord迁移文件夹已经成长到超过150个文件。

There are very old models, no longer available in the application, still referenced in the migrations. I was thinking to remove them.

有非常旧的模型，在应用程序中不再可用，仍然在迁移中引用。我想把它们去掉。

What do you think? Do you usually purge old migrations from your codebase?

你怎么认为?您是否经常从代码基中清除旧的迁移?

10 个解决方案

#1

They are relatively small, so I would choose to keep them, just for the record.

它们相对较小，所以我会选择保留它们，只是为了记录在案。

You should write your migrations without referencing models, or other parts of application, because they'll come back to you haunting ;)

您应该在不引用模型或应用程序其他部分的情况下编写迁移，因为它们将回到您的脑海中;

Check out these guidelines:

看看这些指南:

http://guides.rubyonrails.org/migrations.html#using-models-in-your-migrations

http://guides.rubyonrails.org/migrations.html using-models-in-your-migrations

#2

Once I hit a major site release, I'll roll the migrations into one and start fresh. I feel dirty once the migration version numbers get up around 75.

一旦我点击了一个主要的站点发布，我将把迁移转换为一个并重新开始。一旦迁移版本号上升到75左右，我就觉得很脏。

#3

The Rails 4 Way page 177: Sebastian says...

第177页:Sebastian说……

A little-known fact is that you can remove old migration files (while still keeping newer ones) to keep the db/migrate folder to a manageable size. You can move the older migrations to a db/archived_migrations folder or something like that. Once you do trim the size of your migrations folder, use the rake db:reset task to (re-)create your database from db/schema.rb and load the seeds into your current environment.

一个鲜为人知的事实是，您可以删除旧的迁移文件(同时保留新文件)，以使db/migrate文件夹保持在可管理的大小。您可以将旧的迁移移动到db/archived_migrations文件夹或类似的东西。一旦修改了迁移文件夹的大小，使用rake db:reset task从db/schema创建数据库。将种子装入当前环境。

#4

Why? Unless there is some kind of problem with disk space, I don't see a good reason for deleting them. I guess if you are absolutely certain that you are never going to roll back anything ever again, than you can. However, it seems like saving a few KB of disk space to do this wouldn't be worth it. Also, if you just want to delete the migrations that refer to old models, you have to look through them all by hand to make sure you don't delete anything that is still used in your app. Lots of effort for little gain, to me.

为什么?除非磁盘空间有某种问题，否则我看不出删除它们的好理由。我猜，如果你绝对确信你再也不会像现在这样退缩了。然而，这似乎节省了一些磁盘空间，这样做是不值得的。另外，如果你只是想删除引用旧模型的迁移，你必须手动检查它们，以确保你不会删除仍然在你的应用中使用的任何东西。

#5

Personally I like to keep things tidy in the migrations files. I think once you have pushed all your changes into prod you should really look at archiving the migrations. The only difficulty I have faced with this is that when Travis runs it runs a db:migrate, so these are the steps I have used:

我个人喜欢在迁移文件中保持整洁。我认为，一旦你把所有的变化都推到prod中，你就应该真正考虑到迁移的归档。我遇到的唯一困难是，当Travis运行db:migrate时，我用的步骤是:

Move historic migrations from /db/migrate/ to /db/archive/release-x.y/

将历史迁移从/db/迁移到/db/存档/release-x.y/
Create a new migration file manually using the version number from the last run migration in the /db/archive/release-x.y directory and change the description to something like from_previous_version. Using the old version number means that it won't run on your prod machine and mess up.

使用/db/archive/release-x中上次运行迁移的版本号手工创建一个新的迁移文件。将描述更改为from_previous_version。使用旧版本号意味着它不会在您的prod机器上运行并出错。
Copy the schema.rb contents from inside the ActiveRecord::Schema.define(version: 20141010044951) do section and paste into the change method of your from_previous_version changelog

复制模式。从ActiveRecord内部的rb内容::Schema.define(版本:20141010044951)，并将其粘贴到您的from_previous_version changelog的更改方法中。
Check all that in and Robert should be your parent's brother.

检查一下，罗伯特应该是你父母的兄弟。

The only other consideration would be if your migrations create any data (my test scenarios contain all their own data so I don't have this issue)

另一个要考虑的问题是您的迁移是否创建了任何数据(我的测试场景包含了所有它们自己的数据，所以我没有这个问题)

#6

I occasionally purge all migrations, which have already been applied in production and I see at least 2 reasons for this:

我偶尔会清除所有的迁移，这些迁移已经在生产中应用了，至少有两个原因:

More manageable folder. It is easier to spot if some new migration is added.
更容易管理的文件夹。如果添加一些新的迁移，就更容易发现。
Cleaner text search results (Global text search within a project does not lead to tons of useless matches because of old migration, say, when someone created some column 3 years ago).
更清晰的文本搜索结果(项目中的全局文本搜索不会导致大量无用的匹配，比如3年前有人创建了某个列)。

#7

See http://edgeguides.rubyonrails.org/active_record_migrations.html#schema-dumping-and-you

看到http://edgeguides.rubyonrails.org/active_record_migrations.html schema-dumping-and-you

Migrations are not a representation of the database: either structure.sql or schema.rb is. Migrations are also not a good place for setting/initializing data. db/seeds or a rake task are better for that kind of task.

迁移不是数据库的表示:要么是结构。sql或模式。rb。迁移也不是设置/初始化数据的好地方。db/seed或rake任务更适合这种任务。

So what are migrations? In my opinion they are instructions for how to change the database schema - either forwards or backwards (via a rollback). Unless there is a problem, they should be run only in the following cases:

迁移是什么?在我看来，它们是关于如何更改数据库模式的指令——向前或向后(通过回滚)。除非出现问题，否则只能在以下情况下运行:

On my local development machine as a way to test the migration itself and write the schema/structure file.
在我的本地开发机器上，作为一种测试迁移本身并编写模式/结构文件的方法。
On colleague developer machines as a way to change the schema without dropping the database.
在同事开发机器上，作为在不删除数据库的情况下更改模式的一种方法。
On production machines as a way to change the schema without dropping the database.
在生产机器上，作为在不删除数据库的情况下更改模式的一种方法。

Once run they should be irrelevant. Of course mistakes happen, so you definitely want to keep migrations around for a few months in case you need to rollback.

一旦运行，它们应该是不相关的。当然会出现错误，所以您肯定希望将迁移保持几个月，以防需要回滚。

CI environments do not ever need to run migrations. It slows down your CI environment and is error prone (just like the Rails guide says). Since your test environments only have ephemeral data, you should instead be using rake db:setup, which will load from the schema.rb/structure.sql and completely ignore your migration files.

CI环境不需要运行迁移。它会减慢您的CI环境，并且容易出错(就像Rails指南所说的那样)。由于您的测试环境只有短暂的数据，所以您应该使用rake db:setup，它将从schema.rb/structure中加载。完全忽略迁移文件。

If you're using source control, there is no benefit in keeping old migrations around; they are part of the source history. It might make sense to put them in an archive folder if that's your cup of coffee.

如果您正在使用源代码控制，那么保留旧的迁移没有任何好处;它们是源历史的一部分。如果那是你的咖啡，把它们放在一个文件夹里也许是有意义的。

With that all being said, I strongly think it makes sense to purge old migrations, for the following reasons:

综上所述，我强烈认为清除旧的迁移是有意义的，原因如下:

They could contain code that is so old it will no longer run (like if you removed a model). This creates a trap for other developers who want to run rake db:migrate.
它们可以包含已经过时的代码(如果您删除了一个模型)。这为其他希望运行rake db: migration的开发人员创建了一个陷阱。
They will slow down grep-like tasks and are irrelevant past a certain age.
他们会减缓类似于grep的任务，并且在一定的年龄范围内是无关紧要的。

Why are they irrelevant? Once more for two reasons: the history is stored in your source control and the actual database structure is stored in structure.sql/schema.rb. My rule of thumb is that migrations older than about 12 months are completely irrelevant. I delete them. If there were some reason why I wanted to rollback a migration older than that I'm confident that the database has changed enough in that time to warrant writing a new migration to perform that task.

为什么他们不相关?有两个原因:历史存储在您的源代码控制中，而实际的数据库结构存储在structure.sql/schema.rb中。我的经验是，超过12个月的迁移是完全不相关的。我删除他们。如果有什么原因使我想要回滚一个比我老的迁移，我相信数据库在那个时候已经发生了足够的变化，以保证编写新的迁移来执行该任务。

So how do you get rid of the migrations? These are the steps I follow:

那么如何消除迁移呢?以下是我遵循的步骤:

Delete the migration files
删除迁移文件
Write a rake task to delete their corresponding rows in the schema_migrations table of your database.
编写一个rake任务来删除数据库的schema_migrations表中相应的行。
Run rake db:migrate to regenerate structure.sql/schema.rb.
运行rake db:迁移到重新生成结构。sql/schema.rb。
Validate that the only thing changed in structure.sql/schema.rb is removed lines corresponding to each of the migrations you deleted.
验证在structure.sql/schema中惟一更改的内容。rb被删除，与您删除的每个迁移对应。
Deploy, then run the rake task from step 2 on production.
部署，然后在产品上运行第2步中的rake任务。
Make sure other developers run the rake task from step 2 on their machines.
确保其他开发人员在他们的机器上运行rake任务。

The second item is necessary to keep schema/structure accurate, which, again, is the only thing that actually matters here.

第二项是保持模式/结构的准确性所必需的，这也是这里唯一真正重要的东西。

#8

Yes. I guess if you have completely removed any model and related table also from database, then it is worth to put it in migration. If model reference in migration does not depend on any other thing, then you can delete it. Although that migration is never going to run again as it has already run and even if you don't delete it from existing migration, then whenever you will migrate database fresh, it cause a problem.

是的。我想如果您已经完全从数据库中删除了任何模型和相关的表，那么将它放到迁移中是值得的。如果迁移中的模型引用不依赖任何其他东西，那么您可以删除它。尽管这种迁移不会再运行，因为它已经运行过了，而且即使您不从现有迁移中删除它，那么无论何时您将重新迁移数据库，都会导致问题。

So better it to remove that reference from migration. And refactore/minimize migrations to one or two file before big release to live database.

所以最好从迁移中删除这个引用。在大型发布到live数据库之前，对一个或两个文件进行重构/最小化迁移。

#9

It's fine to remove old migrations once you're comfortable they won't be needed. The purpose of migrations is to have a tool for making and rolling back database changes. Once the changes have been made and in production for a couple of months, odds are you're unlikely to need them again. I find that after a while they're just cruft that clutters up your repo, searches, and file navigation.

当你觉得不再需要旧的迁移时，移除它们是可以的。迁移的目的是有一个工具来进行和回滚数据库更改。一旦做出改变并投入生产几个月，你就不太可能再需要它们了。我发现，在一段时间之后，它们只是一种cruft，使你的repo、搜索和文件导航变得混乱。

Some people will run the migrations from scratch to reload their dev database, but that's not really what they're intended for. You can use rake db:schema:load to load the latest schema, and rake db:seed to populate it with seed data. rake db:reset does both for you. If you've got database extensions that can't be dumped to schema.rb then you can use the sql schema format for ActiveRecord and run rake db:structure:load instead.

有些人会从头开始运行迁移，以重新加载他们的dev数据库，但这并不是他们想要的。您可以使用rake db:schema:load来加载最新的模式，而rake db:seed来填充种子数据。rake db:reset对您来说都是这样。如果您有不能转储到模式的数据库扩展。然后，您可以使用ActiveRecord的sql模式格式并运行rake db:structure:load。

#10

I agree, no value in 100+ migrations, the history is a mess, there is no easy way of tracking history on a single table and it adds clutter to your file finding. Simply Muda IMO :)

我同意，在100+迁移中没有任何价值，历史是一团糟，没有简单的方法跟踪历史记录在一张桌子上，它增加了你的文件发现的混乱。只是穆达国际海事组织:)

Here's a 3-step guide to squash all migrations into identical schema as production:

这里有一个3步指南，可以将所有迁移压缩为与生产相同的模式:

Step1: schema from production

步骤1:从生产模式

# launch rails console in production
stream = StringIO.new
ActiveRecord::SchemaDumper.dump(ActiveRecord::Base.connection, stream); nil
stream.rewind
puts stream.read

This is copy-pasteable to migrations, minus the obvious header

这是对迁移的复制，减去明显的标题。

Step 2: making the migrations without it being run in production

步骤2:在生产环境中不运行迁移

This is important. Use the last migration and change it's name and content. ActiveRecord stors the datetime number in it's schema_migrations table so it knows what it has run and not. Reuse the last and it'll think it has already run.

这是很重要的。使用最后一次迁移并更改它的名称和内容。ActiveRecord在它的schema_migrations表中显示了datetime数字，因此它知道它运行的是什么，而不是。重用最后一个，它会认为它已经运行了。

Example: rename 20161202212203_this_is_the_last_migration -> 20161202212203_schema_of_20161203.rb

示例:重命名20161202212203_this_is_the_last_migration -> 20161202212203_schema_of_20161203.rb

And put the schema there.

把图式放在那里。

Step 3: verify and troubleshoot

步骤3:验证并排除故障

Locally, rake db:drop, rake db:create, rake db:migrate

在本地，rake db:drop, rake db:create, rake db:migrate

Verify that schema is identical. One issue we encountered was datetime "now()" in schema, here's the best solution I could find for that: https://*.com/a/40840867/252799

验证模式是否相同。我们遇到的一个问题是模式中的datetime“now()”，这是我能找到的最好的解决方案:https://*.com/a/40840867/252799

#1