从schema.rb生成迁移文件

han*_*Dev 30 ruby migration ruby-on-rails ruby-on-rails-3

我想从schema.rb生成一个迁移文件.可能吗?

我目前有许多迁移文件,并希望将所有内容合并到一个主迁移文件中.

我也认为我可能在某些时候意外删除了一个迁移文件.

谢谢你的帮助

ghe*_*ton 54

您可以将schema.rb复制并粘贴到迁移中并将其更新(例如更改日期),以便现有数据库不会运行它.创建此迁移后,您可以删除所有旧迁移.

我不同意Andrew,你永远不应该删除迁移.基于模型类的更改,迁移会一直意外中断,修复它们非常简单.由于我确定您正在使用版本控制,因此如果您需要它们以供参考,您可以随时回顾历史记录.

  • 我谦卑地建议迁移不应该依赖于模型类,否则它们将保证随着模型的变化而突破.如果您需要模型的强大功能,则可以在迁移本身中包含一个简单的一次性模型定义. (6认同)
  • 虽然原则上很好,但在实践中很难强制执行. (5认同)
  • @ghempton,谢谢你实际回答问题,而不是说,"没有必要这样做".总是有需要和理由去做别人可能不同意的事情. (5认同)
  • 后退并没有阻止从跑步中移民.Rails 4.2.请参见http://stackoverflow.com/questions/12057408/how-does-rails-keep-track-of-which-migrations-have-run-for-a-database. (2认同)

And*_*all 23

没有必要这样做.对于您应该运行的新安装rake db:schema:load,而不是rake db:migrate,这会将架构加载到数据库中,这比运行所有迁移更快.

您永远不应该删除迁移,当然也不能组合它们.至于意外删除一个,你应该使用版本控制系统,如Git.

  • 你能提供一些证据,这是个坏主意吗? (6认同)
  • 我一直认为使用迁移的目的是能够使用比SQL更方便的语言并重用已经编写过的代码.我很好地考虑了删除迁移,因为你应该使用schema:load而不是migrate,你应该将代码保存在VCS中,删除旧的迁移应该没什么坏处.它只是从未执行过的死代码. (3认同)
  • 在完美的世界中,您不希望删除迁移,但是...删除/重置迁移的另一个真实案例是,如果有人从命令行修改了数据库,并且更改从未添加到迁移(即某人f')编辑流程).这些方案可能会解决迁移与难以识别的数据库之间的差异,因此可能需要执行新的架构转储,删除所有现有迁移,然后将当前架构加载到新的第一次迁移中. (2认同)