为了正确处理 Postgres 的 ForeignKeyViolation 警告,我检查了我的每个模型并添加了 on_delete: 命令,如下所示。
我遵循的格式是
add_foreign_key <:named_table>, <:related_table>, on_delete: :cascade
但是,在进行这些更改并运行 rails db:reset
之后我注意到这些额外的参数没有被传递到生成的 schema.rb 文件中,并且在尝试删除图像时我仍然收到上述错误。
我的程序或语法有什么地方做错了吗?提前致谢!
12345_create_document_images.rb
class CreateDocumentImages < ActiveRecord::Migration[5.1]
def change
create_table :document_images do |t|
t.references :document, foreign_key: true
t.references :image, foreign_key: true
t.timestamps
end
add_foreign_key :document_images, :documents, on_delete: :cascade
add_foreign_key :document_images, :images, on_delete: :cascade
end
end
schema.rb
add_foreign_key "document_images", "images"
add_foreign_key "document_images", "documents"
最佳答案
当你这样说时:
t.references :document, foreign_key: true
foreign_key: true
选项创建相同的外键:
add_foreign_key :document_images, :documents, on_delete: :cascade
确实如此。当 add_foreign_key
方法执行时,FK 已经存在,因此它应该触发一个 PG::DuplicateObject
异常,至少对我来说是这样。我不确定为什么你没有得到异常,但这并不重要,重要的是来自 create_table
的 FK 在你尝试使用 添加 FK 之前会在那里on_delete: :cascade
通过你的 add_foreign_key
调用。
解决方案是让 t.references
使用 on_delete::cascade
创建 FK,并省略显式 add_foreign_key
调用:
class CreateDocumentImages < ActiveRecord::Migration[5.1]
def change
create_table :document_images do |t|
t.references :document, foreign_key: { on_delete: :cascade }
t.references :image, foreign_key: { on_delete: :cascade}
t.timestamps
end
end
end
我还重命名了迁移以匹配它的实际用途。
由 Spectator6 添加:@mu_is_too_short 向我介绍的另一件事是 rails db:migrate:redo
的使用,这让我也了解了 rails db:migrate:reset
。以前,我只使用过 rails db:reset
,但当我实现他的建议然后运行 rails db:migration:reset
后跟 rails db:重置
,一切都点击了!该架构反射(reflect)了新的数据库触发器在 foreign_key 上的表现,并且在开发中尝试了按预期工作的功能。很酷! @mu_is_too_short 的所有 Prop !
关于ruby-on-rails - 为什么我的 add_foreign_key on_delete : :cascade designations not being transferred to the schema,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49439591/