Rails迁移基本工作流程

时间:2014-04-04 21:16:28

标签: ruby-on-rails

假设我有一个创建表'pages'的迁移,这是我的迁移:

class CreatePages < ActiveRecord::Migration
  def up
    create_table :pages do |t|
      t.string "name" , :limit => 50
      t.integer "permalink"
      t.integer "position"
      t.timestamps
    end
  end

  def down
    drop_table :pages
  end
end

并且我已经创建了适当的迁移文件X_create_pages.rb并运行它(该表在数据库中创建)。

现在几天后我意识到结构不完整,我需要在我的页面表中添加另一列。

最佳做法是什么,我是使用add_column方法创建新的迁移文件还是只更改当前迁移文件的up方法-eg只需将我的列添加到up方法(然后向下移动一个版本然后向上移动再次 - 所以运行up方法?)

2 个答案:

答案 0 :(得分:0)

实践应该是创建新的迁移以添加新列。这成为最简单,无风险的途径。当然,我们可以谈论看不见的情况!

应用程序发布到生产后,不应使用更​​新原始迁移文件;至少这是实践应该是什么。但是,这也取决于应用程序,如果您没有在其他地方引用的表,那么备份数据,添加列并恢复数据也是通过这种直接修改原始方法的方法实现的迁移文件并下载该版本并再次迁移该版本。

当你在开发时,我猜你的选择就是你的选择。你可以选择其中一个!

答案 1 :(得分:0)

一旦将迁移检查到源代码管理中,就不应该对其进行更改。

在您的开发环境中修改迁移,前提是它没有被检入源代码管理中,这是完全正常的。

一旦检查了迁移,它可能已由您的团队成员在其开发环境中运行,甚至已在生产中部署和运行。

更改以前提交的迁移将使您在团队中非常不受欢迎,因为团队成员很难理解为什么他们的数据库架构与您的不同,但所有迁移都已运行。