回滚后我应该删除迁移吗答案

【问题标题】：Should I delete migration after rollback回滚后我应该删除迁移吗
【发布时间】：2014-08-04 23:23:06
【问题描述】：

我对 ruby 和 rails 还很陌生，刚刚开始了解迁移。

我的问题是在回滚后删除迁移的最佳做法或正确时间是什么？到目前为止，我所读的是一个意见问题，您是否在回滚后删除迁移，但是在团队中工作时删除迁移是否有任何重大影响，以及离开迁移文件而不是删除有什么好处是吗？

在我的情况下，什么最有意义？

我有我的原始迁移文件 20140731141350_create_users.rb

class CreateUsers < ActiveRecord::Migration
  def change
    create_table :users do |t|
      t.string :email
      t.string :password

      t.timestamps
    end
  end
end

我需要向其中添加一个 salt 列，因此我创建了迁移 20140804125449_add_salt_colum_to_users.rb

class AddSaltColumToUsers < ActiveRecord::Migration
  def change
    add_column :users, :salt, :string
  end
end

但在开发过程中，我意识到 salt 列不是必需的并执行了

rake db:migrate:down VERSION=20140731141350

现在我剩下一个未使用的 20140804125449_add_salt_colum_to_users.rb 迁移文件。

删除还是不删除？

【问题讨论】：

如果不需要，删除它。

标签： ruby-on-rails ruby rails-migrations

【解决方案1】：

您永远不应该更改旧的迁移。如果您意识到给定的列是不必要的，请编写一个新的迁移来删除它。

这样做的原因是您可以在任何开发点恢复数据库模式。如果您在团队中工作，则删除迁移这一事实不会改变您队友的架构。更重要的是，他们现在没有迁移可恢复！

【讨论】：

对我来说，一个例外是如果你没有推动迁移
没错，如果 mig 有可能影响到某人，那就把它留在那里。如果没有，删除它，它只会使事情复杂化。
这就是我的想法。我正在本地开发并且没有向团队推送任何内容，因此我的更改不会影响任何人，因此是否需要创建另一个迁移来撤消添加盐列的迁移？然后，我将基本上创建 2 个迁移，让我回到原来的迁移，这对我来说似乎很乱......
@SteWoo - 保留它们的另一个原因是历史一致性。如果您想查看您的应用程序在给定时间的行为方式，您可能会不走运并获得您的应用程序确实具有此字段的历史记录点。迁移文件当时确实存在，因此您更新架构，然后需要重新还原它。但是，如果您还没有推送它并且这是您最近的迁移，我认为没有理由保留它。但是请注意，这是一个例外而不是规则。

【解决方案2】：

看看这个blog post 关于rails 迁移。如本文所述：

当我启动一个新环境时，运行 rake 会容易得多数据库：架构：负载。而且迁移是多余的。所有这些数据都是在架构文件中。

因此，如果没有其他迁移依赖于此迁移，我建议您删除此迁移。

【讨论】：

【解决方案3】：

永远不要删除或编辑您的旧迁移！与团队合作甚至单独工作都会给您的应用程序带来很多伤害。

【讨论】：