ruby-on-rails - Rails 对 :dependent => :destroy and cascade delete/nullify/restrict 有什么作用

Question

我正在尝试决定如何最好地为我的 rails 应用程序设置(如果有的话)外键约束。我有一个型号Response那belongs_to一个 Prompt .我想使用 :dependent => :destroy每个 Response 都需要销毁属于已删除的 Prompt我正在尝试决定我应该在我的外键上放置什么删除约束。

简而言之，我想得到关于如何最好地利用依赖对象的销毁方法和外键约束的建议，以确保 cruft 不会累积并反射(reflect)所存储数据的逻辑结构。几个较早的问题，例如 Should I use ON DELETE CASCADE, :dependent => :destroy, or both?和 Rails: delete cascade vs dependent destroy问哪个更好，但他们并没有真正说明这两个选择如何相互作用以及它们以什么顺序被触发或在这一点上似乎含糊不清。

在我看来，考虑因素似乎分为几部分:

是否 :dependent => :destroy在从数据库中删除父对象之前首先在依赖对象上调用destroy，所以即使我使用级联删除，仍然会在这些对象上调用destroy？

是否 :dependent => :destroy在从数据库中删除父对象之前(或在事务中)从数据库中删除依赖对象？换句话说，如果我将 cascade 设置为 nullify，那么数据库是否会在子对象被删除之前浪费地取消对子对象的引用？

是否由于原始破坏和链接而发出删除 :dependent => :destroy包裹在事务中的选项，或者如果我不设置级联删除，不幸的是，定时崩溃会在数据库中留下垃圾？

最后会:dependent => :destroy如果我使用限制作为外键 on_delete 选项，确保从数据库中删除父对象？

Answer 1

与 dependent: :destroy在事务中，rails 首先销毁所有依赖项，然后才删除记录本身。

可能存在竞争条件:如果在 Rails 读取集合之后添加了依赖记录以进行销毁，但尚未删除父记录 - 它可能会被遗留下来。让我们在下面称这些“竞争条件记录”。

是的，您可以使用 dependent: :destroy和 on delete cascade ，这样一些 child (竞争条件的 child )可以在没有回调的情况下被删除。如果回调是强制性的 - on delete restrict加上一些锁定和显式删除子项可能会更好。
这有点像 validates :some_field, uniqueness: true最好有唯一索引支持，只有数据库本身才能保证数据的一致性。

由于最后删除了父级，on delete nullify不会妨碍(您将获得无效的竞争条件记录)

有事务包装所有删除，只能留下竞争条件记录

on delete restrict超过 dependent: :destroy只会触发竞争条件记录(并回滚整个事务)，但如果没有竞争条件 - rails 会愉快地删除所有内容。