【问题标题】:Active record migrations and refactoring活动记录迁移和重构
【发布时间】:2012-09-08 12:14:37
【问题描述】:

我正在对我当前的项目进行相当陡峭的重构。在到达这个十字路口之前,我有两个模型,我意识到它们实际上是相同的模型,但处于不同的状态,我想以这种方式表示系统。结果,我必须将即将失效的模型的所有对象移到另一个模型中并正确设置新的状态列。这个问题在代码方面很简单,特别是因为模型非常相似。

对我来说,痛点是我必须在双向迁移的某个中间点进行这些更改。从这里到那里的路径有点像:

add_column :model_ones, :status, :string

make_all_model_two_records_into_model_one_records()

drop_table :model_twos

显然另一个方向也很容易定义

create_table :model_twos do |t|
  ...
end

move_model_ones_with_status_x_into_model_twos_table

remove_column :model_ones, :status

这是一件好事,但是当我从我的仓库中删除 ModelTwo.rb 的那个神奇时刻时,整个事情就变成了锅。那时,我永远无法在不阅读该源代码的情况下从头开始迁移。我对此的反应是要么直接编写 sql 来来回移动数据,要么将数据转换从迁移中取出。如果我把它拿出来,它到底跑到哪里去了?在迁移时如何确保它在正确的时间发生?

假设我克服了这方面的问题,我现在可以愉快地从零迁移到现在。我永远不能向下迁移,对吗?这是否代表了某个时刻,分阶段迁移的概念对我来说已经死了?

我想我可以回去按摩早期的迁移,以让世界相信 ModelTwo 根本不存在,但是一想到违反现有迁移的神圣性,我就感到毛骨悚然。

人们必须在某个地方使用 Rails 进行这种重构。它必须是可行的,对吧?我不知道该怎么做。

提前致谢, jd

【问题讨论】:

  • 我没有看到问题。为什么在删除 model_twos 后不能“从头开始迁移”?它被创建并再次删除......有什么问题?

标签: ruby-on-rails refactoring rails-migrations


【解决方案1】:

我愿意:

  1. 创建添加状态列的迁移

  2. 运行 rake 任务来移动数据

  3. 测试所有正确移动的数据

  4. 运行另一个迁移以删除不需要的旧表。

有时您需要更改旧的迁移以确保您可以轻松构建开发环境。我不知道你为什么认为这是一个问题。迁移可以帮助您,而不是您应该感到有义务遵守的一些神奇规则。

有时您可能会过于拘泥于最佳实践,而忘记了很难制定适用于所有情况的“最佳实践规则”。它们可以作为很好的指南,但最终最佳实践是为您的项目做最好的事情。

【讨论】:

    猜你喜欢
    • 2015-10-06
    • 1970-01-01
    • 2022-09-23
    • 2014-06-15
    • 2013-07-27
    • 1970-01-01
    • 1970-01-01
    • 2012-02-20
    • 2013-05-07
    相关资源
    最近更新 更多