Rails对这两者有什么作用：depend => ：destroy和级联删除/无效/限制 [英] What Does Rails Do With Both :dependent => :destroy and cascade delete/nullify/restrict

问题描述

我正在尝试确定如何最好地为Rails应用程序设置（如果有的话）外键约束。我有一个模型 Response ，该模型属于提示。我想使用：dependent => ：destroy 在属于已删除的提示的每个响应中调用破坏命令，而我

I'm trying to decide how best to set up (if at all) foreign key constraints for my rails application. I have a model Response that belongs_to a Prompt. I would like to use :dependent => :destroy to have destroy called on every Response that belongs to a deleted Prompt and I'm trying to decide what delete constraint I should place on my foreign key.

简而言之，我想就如何最好地利用这两种上的destroy方法提供建议。依赖对象和外键约束，以确保不会堆积数据并反映所存储数据的逻辑结构。之前有几个问题，例如我应该使用ON DELETE CASCADE， ：dependent => ：destroy，还是同时使用？和导轨：删除级联与依赖性破坏询问哪个更好，但他们并没有真正就两种选择如何相互作用以及它们以什么顺序被触发或就这一点而言似乎含糊其辞。

In short I want advice about how I can get best take advantage of both the destroy method on dependent objects and foreign key constraints to ensure cruft doesn't accumulate and reflect the logical structure of the data being stored. Several earlier questions such as Should I use ON DELETE CASCADE, :dependent => :destroy, or both? and Rails: delete cascade vs dependent destroy asked which was better but they don't really say much about how the two choices interact and in what order they are triggered or seemed vague on the point.

如我所见，考虑因素似乎分为几部分：

As I see it the considerations seem to break up into a few pieces:

1. 是否：dependent = > ：destroy 在从数据库中删除父对象之前先对依赖对象进行销毁，所以即使我使用级联删除，销毁仍将在这些对象上调用？



2. 是否：dependent => ：destroy 从数据库中删除父对象之前（或与之相关的事务中）从数据库中删除依赖对象？换句话说，如果我将层叠设置为null，那么数据库将在删除子对象之前最终浪费掉对这些对象的引用吗？

1. Does :dependent => :destroy call destroy first on the dependent objects before removing the parent from the database so destroy will still be called on these objects even if I use cascade delete?

2. Does :dependent => :destroy remove the dependent objects from the database before (or in a transaction with) removing the parent from the database? In other words if I set cascade to nullify will the database end up wastefully nullifying the references on the child objects before they are deleted?

是否将删除作为原始销毁并链接的结果：dependent => ：destroy 包装在事务中的选项，或者如果我不设置级联删除，不幸的是，定时崩溃将使数据库崩溃？

Are deletes issued as a result of the original destroy and chained :dependent => :destroy options wrapped in a transaction or will unfortunately timed crashes leave cruft in the database if I don't set cascade delete?

推荐答案

在事务中具有 dependent：：destroy 的依赖项首先会破坏所有依赖项，然后才删除记录本身。

With dependent: :destroy in a transaction rails first destroys all dependencies, and only then deletes the record itself.

可能存在争用条件：如果在rails读取要销毁的集合后添加了相关记录，但尚未删除父记录，则该记录会被保留。让我们将这些称为种族条件记录。

There may be a race condition: if a dependent record was added just after rails read collection for destroying, but not deleted parent yet - it may be left over. Let's call these "race condition records" below.

1. 是的，您可以使用 dependent：：destroy 和删除级联，这样可以删除某些子级（种族条件的子级）而无需回调。如果回调是强制性的-在删除限制上 加上一些锁定和显式子删除可能更好。
   这有点像 validates：some_field，uniqueness：true 最好由唯一索引支持，只有数据库本身才能确保数据一致性。

1. yes, you can use dependent: :destroy and on delete cascade, this way some children (race condition ones) can be deleted without callbacks. If callbacks are mandatory - on delete restrict together with some locking and explicit children deletion may be better. This is somewhat like validates :some_field, uniqueness: true that is better to be backed by unique index, only database itself can ensure data consistency.

由于父级最后一次删除，删除时无效不会妨碍您的操作（您将获得无效的竞争条件记录）

since parent is deleted last, on delete nullify will not get in the way (you'll get nullified race condition records)

其中有所有删除操作的交易记录，只能保留比赛条件记录

there's transaction wrapping all deletes, only race condition records can be left over

在删除限制上超过从属：：destroy 仅会触发竞争条件记录（并回滚整个事务） ，但如果没有比赛条件-滑轨会愉快地删除所有内容。

on delete restrict over dependent: :destroy will trigger only for race condition records (and roll back whole transaction), but if there was no race condition - rails will happily delete everything.

这篇关于Rails对这两者有什么作用：depend => ：destroy和级联删除/无效/限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！