从 Rails 1.2.3 应用程序升级时如何更新迁移?
我正在将 Rails 1.2.3 应用程序更新到 3.2.1。
我正在尝试弄清楚如何更新迁移结构以与最新版本的 Rails 兼容,以便理想情况下,您可以在设置应用程序时运行 rake db:migrate
。目前,我通过对需要运行的任何迁移进行 rake db:migrate:up VERSION=[version_number]
来解决这个问题。如果我只是运行 rake db:migrate ,它会尝试从头开始重新运行所有迁移,然后停止(因为这些迁移已经在我的数据库转储中运行)。
应用中的迁移类似于 001_add_some_model.rb
、002_add_some_other_model.rb
,而不是 20120209182512_add_some_model.rb
。
有人有这方面的经验吗?我该如何解决这个问题?
I'm updating a Rails 1.2.3 app to 3.2.1.
I'm trying to figure out how I can update the migration structure to be compatible with the latest version of Rails, so that, ideally, you can just run rake db:migrate
when setting up the app. Currently, I have solved this by just doing rake db:migrate:up VERSION=[version_number]
of whatever migration I need to run. If I just run rake db:migrate
, it tries to rerun all of the migrations from the beginning and it stops (since those migrations have already been run in the db dump I have).
Migrations in the app look like this 001_add_some_model.rb
, 002_add_some_other_model.rb
instead of 20120209182512_add_some_model.rb
.
Does anyone have any experience with this? How can I fix this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我认为您应该重新启动您的迁移,删除您拥有的所有迁移,并使用当前模型的定义创建一个新的迁移。请参阅此迁移作为起始示例。
I think you should restart your migrations, drop all the migration you have and create a new migration with definitions of your current models. See this migration as a starting example.
即使在最新的 Rails 3 应用程序中,也不建议运行所有迁移来设置新数据库。这在 db/schema.rb 中有解释:
It is not recommended to run all migrations to set up a new database even in an up-to-date Rails 3 app. This is explained in db/schema.rb:
我会从头开始创建新的迁移,而不是建议的内容。
在当前状态下启动所有模型,并为每个模型创建新的迁移,这样您以后仍然可以使用迁移的功能,例如向表添加列或更改列类型。
如果您为所有模型创建单个迁移,就像有有人建议您将丢失迁移名称中的模型轨道。
这只是另一种方法,反映了我自己的愿景。
Instead of what had been suggested, I would create new migrations from scratch.
Start you all your models at the current state and create new migrations for each of them, this way you could still use the power of the migrations later, like adding a column to a table or change a column type.
If you create a singe migration for all your models, like has been suggested you'll loose the model track in migrations name.
This is just another way to do it and reflects my own vision.