Rails:我更新迁移文件然后运行 db:migrate,但我的架构没有更新
我正在尝试向我的一张表添加一个额外的字段。
我已在迁移文件中添加了该字段(在 db\migrate 下), 然后运行“rake db:migrate”,运行顺利。我的文本编辑器甚至告诉我我的 schema.db 文件已更新并且需要刷新。
架构文件不包含我的新字段,并且从我的视图中引用该字段的任何尝试都惨败。
我该怎么做?是否可以通过 Rails 更新带有额外字段的表,而不必完全删除并重新创建数据库?
I'm trying to add an extra field to one of my tables.
I've added the field in the migration file (under db\migrate),
then ran 'rake db:migrate' which ran without troubles. My text editor even told me my schema.db file has been updated and needs to refresh.
The schema file does not contain my new field and any attempts to reference the field from my views fail miserably.
How do I do this? It is possible to update a table with an extra field via rails without having to totally drop and recreate the database again?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
http://guides.rubyonrails.org/migrations.html#changing-existing-migrations
在数据库中添加/更改某些内容时,您应该始终创建一个新的迁移文件。这就是迁移的目的。迁移文件应该能够进行新的更改和撤消更改。这样,如果出现问题或者您改变了主意,您可以轻松回滚到之前的迁移。
以下链接中标有“迁移剖析”和“编写迁移”的部分可能对您有帮助。
http://guides.rubyonrails.org/migrations.html
You should always create a new migration file when adding/changing something in the database. This is the purpose of migrations. A migration file should have the ability to make the new change and undo the change. This way if something goes wrong or you changed your mind you can easily roll back to a previous migration.
The following link's sections labeled 'Anatomy of a Migration' and 'Writing a Migration' might be of help to you.
http://guides.rubyonrails.org/migrations.html
我做了同样的事情,我想更改字段名称并且
而不是这个:
我改为
我
尝试做 rake
没有发生任何事情,因为它再次进入命令提示符而没有任何输出...,我查看了堆栈溢出和
12122087/update-db-migrate-after-manually-updating-models">这引导我在没有输出的情况下
,然后我用commenter_body而不是body加载我的页面/控制器,并且它加载完美。
我认为这也是一个解决方案。我不知道模型/数据库的底层工作是否有任何问题(我对 RoR 还很陌生,实际上是我的第三天......)
I did the same thing, I wanted to change a field name and
instead of this:
I changed
to
I tried doing rake
nothing happened as in it went to the command prompt again without any output..., i looked at stack overflow and this guided me to do rake
with out put
and then I loaded my page/controller with commenter_body instead of body and it loaded perfectly.
I think this is also a solution to the same. I dont know if there is any issue in the underneath workings in the model/DB( i am still very new to RoR,my third day actually...)
解决了我自己的问题..
基本上,不是编辑运行脚手架时生成的原始迁移文件,而是为您想要实现的目标创建一个新的迁移文件:
http://guides.rubyonrails.org/migrations.html#creating-a-standalone-migration
Solved my own Question..
Basically rather than edit the original migration files generated when you run scaffolding you create a new migration file just for what you want to acheive:
http://guides.rubyonrails.org/migrations.html#creating-a-standalone-migration
我能够通过运行 rake db:schema:dump 来重新生成后续迁移的架构
I was able to regenerate my schema with latter migrations by running
rake db:schema:dump
一旦你执行了 rake db:migrate ,那么你就无法将列添加到该文件中。你必须使用rails g migration add_columnname_to_tablename 生成一个新的迁移文件来添加该特定列,然后执行 rake db:migrate 。就是这样!
Once u do rake db:migrate then again u cannot add column to that file.You have to generate a new migration file by using rails g migration add_columnname_to_tablename for adding that particular column and do rake db:migrate.That's it !!!
不知道这是否适用,但值得一试。直接来自“使用 Rails 进行敏捷开发,第 3 版”:
有时,这个 schema_migrations 表可能会给您带来问题。例如,如果您创建
迁移源文件并在向文件添加任何架构定义语句之前运行 db:migrate,
数据库会认为它已更新,并且模式信息表将包含新版本
数字。
如果您随后编辑现有迁移文件并再次运行
db:migrate
,Rails 将不知道应用您的新更改。在这些情况下,通常最简单的方法是删除数据库,然后重新创建
它,并重新运行您的迁移。
Don't know if this applies, but it's worth a shot. Straight from "Agile Development with Rails, 3rd edition":
Sometimes this schema_migrations table can cause you problems. For example, if you create the
migration source file and run
db:migrate
before you add any schema-defining statements to the file,the database will think it has been updated, and the schema info table will contain the new version
number.
If you then edit that existing migration file and run
db:migrate
again, Rails won’t know toapply your new changes. In these circumstances, it’s often easiest to drop the database, re-create
it, and rerun your migration(s).