7

在开始一个新项目时，模型中有很多变化，我发现编辑现有迁移并运行db:clean或db:reset创建新迁移更容易。当应用程序尚未投入生产时，我会这样做，这意味着我可以毫无顾虑地重置/清理数据库并且我正在单独工作或作为一个小团队的一部分工作。

但是今天，我在Rails Guide中看到了以下建议，说这不是一个好主意，并且不鼓励编辑现有的迁移：

编辑现有迁移不是一个好主意：如果现有版本的迁移已经在生产机器上运行，您将为自己和您的同事创建额外的工作，并且会引起严重的麻烦。相反，您应该编写一个新的迁移来执行您需要的更改。编辑尚未提交到源代码控制（或更一般地说，尚未传播到您的开发机器之外）的新生成的迁移相对无害。

我想知道：

  • 我会遇到什么潜在的陷阱？
  • 这些陷阱是否适用于我的案例（开发阶段，单独工作）？
4

4 回答 4

10

如果您正在与团队合作并且您提交了迁移，那么 NO。

如果它仅在您的本地环境中，那么只需创建一个新的迁移来修复您需要的内容。您可以删除表\列并执行您需要的操作。

由于您清理了数据库并重置了它，那么每个人都会做同样的事情，否则如果他们尝试迁移就会遇到问题。

于 2012-05-30T07:59:36.390 回答
1

我正在开发模式下的网络应用程序。虽然我一个人工作，但最好使用迁移来修改数据库。它可能会留下修改痕迹，但您可以看到数据库结构的演变。从长远来看，您将更快地解决迁移的数据库问题。

于 2013-07-08T22:50:18.397 回答
0

数据库迁移是一种工具。像任何工具箱一样，最重要的是了解它的用途、如何使用它以及为什么要这样使用它。

  • 实时站点：在实时站点中，您不能简单地使用 rake:db reset，因为显然您需要所有这些数据
  • 协作：您需要与其他开发人员保持迁移的一致性。如果他们已经将数据输入到他们的数据库中（无论出于何种目的）并简单地混合在您的代码中会怎样。您现在已经完全放弃了他们的努力，他们将被迫重置他们的整个数据库
  • Rake db:rollback ：一旦你修改了你必须重置的代码，现在你不能运行回滚。
  • 这是一个坏习惯：在大多数情况下，这样做的礼貌方式是创建一个新的迁移。最好养成能够快速有效地创建新迁移的习惯和心态。

我实际上并不是在告诉你不要这样做。这些只是为什么不按照我的看法去做的要点。在大多数情况下，如果您一个人，或者特别是如果您刚刚形成您的项目（并且可能不会立即意识到您希望数据库如何查看/直接使用它们可能是最有效的。了解原因很重要因此，在您反对最佳实践之前。

于 2015-01-05T06:06:41.390 回答
0

一旦你提交了迁移到 git，只要它不是数据破坏或 CI 崩溃的事情，你不应该改变它。这对整个概念来说是不言自明的！

问题是，一旦应用了迁移，它就不会再次运行，如果你不得不重新开始，你就会冒着意外丢失数据的风险。您应该始终只创建一个新的迁移。

有一个例外，也是一个棘手的例外，与删除依赖项有关。在有限情况下 ORM 涉及第三方的迁移所面临的问题之一是依赖关系是非此即彼的。它们要么存在，要么不存在。因此，如果在某个时刻添加了一个依赖项，然后从模型创建外部引用，并将其存储在迁移中，然后删除该依赖项，当您从头开始运行迁移时，链接到的依赖项迁移将失败，因为外键的目标不再存在。这是一个很大的问题，因为在这种情况下，您实际上需要编辑旧迁移以删除外键，但您还需要对现有安装进行迁移以删除密钥。这里的一般模式是，如果您的迁移系统是可编写脚本的，请检查该密钥是否存在，然后仅在那时删除该密钥，否则，跳过删除。顺便提一下，try {} except {} 类型结构在这里可能是错误的选择，因为一些 ORM 会在引发任何类型的异常以避免损坏时回滚排队写入的事务。

So generally, no please dont edit existing migrations, but if its in those limited situations where externalities dictate a requirement, proceed with very delicate care.

于 2021-07-19T06:24:46.673 回答