我从git中提取了新更改,在此新更改中有一个迁移文件,
def change
add_column :users, :activated_at, :datetime
User.all.each do |user|
user.update(activated_at: user.updated_at)
end
end
现在通常情况下,如果我要撤消迁移,即删除一列“ activated_at”,我必须运行另一个迁移来这样做
但是如果我只想删除脚本,即user.update(activated_at: user.updated_at)
,我是否必须创建另一个迁移,还是从迁移中删除脚本。
注意:我不想删除Activated_at列,我只想删除脚本
答案 0 :(得分:2)
您只需删除代码并在master分支中提交即可。
对于运行此迁移的系统,您可以运行rake task来运行您想要回滚的任何内容(即,将activated_on
设置为nil)。或者,您可以从Rails控制台运行以将其设置为零。
对于要克隆和创建数据库并运行迁移的新系统,在删除代码时它不会与脚本保持联系。
答案 1 :(得分:0)
我的回答有些细微差别。简而言之,您会问:您可以更改已经运行的迁移吗?一般来说,我会建议不要这样做。在您的情况下,它还取决于activated_at
字段将要发生的情况,我可以想象只有在用户被“激活”之后(无论在您的应用程序上下文中意味着什么),才可以设置它。因此,在这种情况下:将其设置为updated_at
是错误的,并且必须“未设置”?还是以其他方式设置?因此无论如何都需要迁移。或者,也有可能:例如,迁移尚未在您的生产服务器并以这种方式运行迁移将很难以一种好的方式来撤消(在这种情况下,这很简单--再次将Activate-at设置为nil),然后一定要适应迁移,提交并根据部署它将运行更好迁移。但是...您将必须在迁移 did 运行的所有计算机上手动恢复/修复该情况(您的计算机,您的同事,暂存测试平台?...)
因此,可以帮助您进行决策流程
master
(所有代码均保持本地状态),请随意进行迁移:P 顺便说一句:我见过那些渴望只在git中拥有“完美”代码的开发人员,他们将使用git提供的所有选项来清理代码:回顾历史,壁球提交,我不得不承认结果很明显。那是非常诱人和可以理解的,但是恕我直言,我们失去了信息(我们是如何到达这里的,为什么?)。同样,进行干净且最少的迁移也很诱人,但就我个人而言,我相信git和您的迁移“显示”对问题区域的日益增长的理解并没有什么可耻的。我认为这是被称为“开发”的原因之一:构建软件是一个非常反复的过程,并且它会不断变化,并且您的代码(git /历史记录)和迁移都可以反映这一点。如果最后一部分太过主观,我深表歉意。