Django中的ON-DELETE级联逻辑在哪里实现？（使用PostgreSQL）

我只需要你们Django专家确认我对Django实施on DELETE CASCADE的理解

根据Django官方文件：

当Django删除一个对象时，默认情况下它模拟 DELETE CASCADE上的SQL约束——换句话说，任何对象 外键指向要删除对象的对象将被删除 随它一起删除

单词“仿真”是否意味着ON-DELETE级联逻辑实际上是在Django中实现的，而不是在数据库级别实现的？（我查看了我的数据库，所有包含外键的表在其定义中都没有删除操作。）

---

如果我的理解是正确的，有没有办法将ON-DELETE级联逻辑从应用层重新定位到数据库层？我更多的是在寻找一种合适的方法，而不是一种技巧。（注意：我使用PostgreSQL作为我的后端。）

仅供参考，自django 1.3以来，这是可配置的：

基本上，您需要设置为on_delete以不执行任何操作，并自己将级联逻辑添加到DB中：

> DELETE FROM accounts_publisher WHERE id=5;
ERROR:  update or delete on table "accounts_publisher" violates foreign key constraint "accounts_publisher_id_411559b18a178e73_fk_accounts_publisher_id" on table "accounts_membership"
DETAIL:  Key (id)=(5) is still referenced from table "accounts_membership".

什么都不做：不要采取行动。如果您的数据库后端强制引用完整性，这将导致IntegrityError，除非您手动将SQL ON DELETE约束添加到数据库字段（可能使用初始SQL）

---

如果您询问相关代码在哪里实现：您可以找到它

在应用程序/ORM层中实现级联-删除逻辑是有意义的，因为这使应用程序能够在删除发生时得到通知（例如，Django的删除信号针对删除的实例触发），此外，在不同类型的数据库中启用此功能也是一种明智的方法

如果您担心数据的完整性：如果您的数据库支持外键约束，Django仍然会设置外键约束（例如，检查Postgresql）。因此，数据库不允许删除外键指向的任何行

你自己试试吧：

> DELETE FROM accounts_publisher WHERE id=5;
ERROR:  update or delete on table "accounts_publisher" violates foreign key constraint "accounts_publisher_id_411559b18a178e73_fk_accounts_publisher_id" on table "accounts_membership"
DETAIL:  Key (id)=(5) is still referenced from table "accounts_membership".

---

为什么？如果它通过Django ORM工作（适当维护ORM缓存，向应用程序发送适当的信号，等等），为什么要绕过这个非常完整和复杂的ORM层呢？S.Lott-我坚信数据库应该自己保持完整性。看到ON-DELETE级联在应用程序层（例如Django）进行处理是很好的，但是在Django世界之外，这种特性并不总是可用的。如果有一天有一些非Django应用程序访问和删除我数据库中的记录，但它不处理DELETE CASCADE，而是假设数据库可以完成这项工作，该怎么办。我的数据库会有大麻烦。这就是为什么我有点担心ondelete-CASCADE没有在数据库级别应用。“如果有一天有一些非Django应用程序访问和删除我数据库中的记录”。然后有人犯了一个可怕的错误。这就像问“如果一个具有root权限的操作系统进程删除了一个数据库文件怎么办？”或者“如果一个恶意用户运行一个删除所有数据库记录的应用程序怎么办？”防止这些事情很简单。不，不是。多个应用程序使用同一个数据库是很常见的。您的整个断言就像在Javascript中隐藏表单字段，而不是在服务器端验证表单数据：（更不用说通过Django ORM进行批量删除可能需要几个小时。好吧，Django只模拟这种行为。为什么Django不像最初的问题所问的那样，在FK中直接在数据库级别设置行为？我想补充一点，在#21961（）谢谢@SimonCharette。很高兴知道这一点。“数据库的效率可以大大提高，而且通常可以避免锁定情况。”。这张罚单描述了我对在Django中使用CASCADE-DELETE逻辑而不是数据库本身的确切关注。我认为这对于开发人员来说是一个很好的选择。Bernhard-这个问题几乎是四年前提出的。自从n、 显然，我关心的不是数据完整性，而是为什么要付费的问题（性能和可能的锁定情况）用于复制数据库层中已有的逻辑。如您所述，我同意数据库不可知可能是核心团队做出此决定的一个重要原因。@tamakisquare，另一个原因是您的应用程序可以对删除的实例做出反应（例如，使用

pre_delete

/

post_delete

）信号。。。