Fixed #21961 -- Added support for database-level delete options for ForeignKey. #19925

felixxm · 2025-10-07T09:54:32Z

ticket-21961

LilyFirefly

A couple minor suggestions.

django/db/backends/base/schema.py

django/db/models/deletion.py

jacobtylerwalls

Looking great. Took a look at docs and a first look at the implementation.

I think changes are pending to the system checks. When that's in, I'll look at that, the tests, the django.contrib changes, and do some manual testing.

docs/ref/models/querysets.txt

docs/ref/models/fields.txt

docs/releases/6.1.txt

django/db/models/fields/related.py

django/db/models/__init__.py

charettes · 2025-10-10T20:44:38Z

@felixxm as discussed, I just pushed the nested admin collector tests for DB_CASCADE and DB_RESTRICT here

django/contrib/contenttypes/fields.py

charettes · 2025-10-10T20:48:19Z

tests/invalid_models_tests/test_relative_fields.py

 from django.core.checks import Warning as DjangoWarning
 from django.db import connection, models
-from django.test.testcases import SimpleTestCase
+from django.test import skipUnlessDBFeature


Not related to your changes but this module should be named test_related_fields, there's no such thing as a relative field 😅

Good catch 🎯 Let's rename it when this is merged.

felixxm · 2025-10-10T21:18:51Z

@felixxm as discussed, I just pushed the nested admin collector tests for DB_CASCADE and DB_RESTRICT here

Thanks 👍 Merged 🎉

…oreignKey. Thanks Simon Charette for pair programming. Co-Authored-By: Nick Stefan <NickStefan12@gmail.com> Co-Authored-By: Akash Kumar Sen <71623442+Akash-Kumar-Sen@users.noreply.github.com> Co-Authored-By: Simon Charette <charette.s@gmail.com>

felixxm · 2025-10-11T17:37:31Z

buildbot, test on oracle.

felixxm · 2025-10-11T20:45:54Z

buildbot, test on oracle.

adamchainz · 2025-10-11T22:20:35Z

django/contrib/admin/utils.py

    def __init__(self, *args, **kwargs):
+        kwargs.setdefault("force_collection", True)
        super().__init__(*args, **kwargs)


Why not put this in the signature?

Suggested change

def __init__(self, *args, **kwargs):

kwargs.setdefault("force_collection", True)

super().__init__(*args, **kwargs)

def __init__(self, *args, force_collection=True, **kwargs):

super().__init__(*args, force_collection=force_collection, **kwargs)

adamchainz · 2025-10-11T22:22:38Z

django/db/models/base.py

+                            "The model cannot have both related fields with "
+                            "database-level and python-level on_delete variants.",


Grammar fix:

Suggested change

"The model cannot have both related fields with "

"database-level and python-level on_delete variants.",

"The model cannot have related fields with both "

"database-level and python-level on_delete variants.",

adamchainz · 2025-10-11T22:32:08Z

docs/ref/models/querysets.txt

+If ``DB_*`` options are used, Django doesn't need to fetch objects into memory
+to send signals and handle cascades. However, if there are no cascades and no
+signals, then Django may take a fast-path and delete objects without fetching
+into memory. For large deletes this can result in significantly reduced memory
+usage. The amount of executed queries can be reduced, too.


The current edit doesn't really make sense: "However, ..." doesn't connect. My attempt to clarify:

Suggested change

If ``DB_*`` options are used, Django doesn't need to fetch objects into memory

to send signals and handle cascades. However, if there are no cascades and no

signals, then Django may take a fast-path and delete objects without fetching

into memory. For large deletes this can result in significantly reduced memory

usage. The amount of executed queries can be reduced, too.

Django won’t need to fetch objects into memory when deleting them in two cases:

1. If related fields use ``DB_*`` options.

2. If there are no cascades and no delete signal receivers.

In these cases, Django may take a fast path and delete objects without fetching

them, which can result in significantly reduced memory usage and fewer executed

queries.

adamchainz · 2025-10-11T22:32:39Z

docs/ref/checks.txt

+* **models.E049**: The model cannot have both related fields with
+  database-level and python-level ``on_delete`` variants.


Suggested change

6D38

* **models.E049**: The model cannot have both related fields with

database-level and python-level ``on_delete`` variants.

* **models.E049**: The model cannot have related fields with both

database-level and python-level ``on_delete`` variants.

adamchainz · 2025-10-11T22:36:48Z

docs/releases/6.1.txt

+The database variants are more efficient because they avoid fetching related
+objects, but ``pre_delete`` and ``post_delete`` signals won't be sent when
+:attr:`~django.db.models.DB_CASCADE` is used.


I think we can spell out how they work a bit more, to help readers with some SQL knowledge make the connection, and to promote the feature.

Suggested change

The database variants are more efficient because they avoid fetching related

objects, but ``pre_delete`` and ``post_delete`` signals won't be sent when

:attr:`~django.db.models.DB_CASCADE` is used.

These options handle deletion logic entirely within the database, using the SQL

``ON DELETE`` clause. They are thus more more efficient than the existing

Python-level options, as Django does not need to load objects before deleting

them. As a consequence, the :attr:`~django.db.models.DB_CASCADE` option does

not trigger the ``pre_delete`` or ``post_delete`` signals.

felixxm marked this pull request as draft October 7, 2025 09:54

felixxm changed the title ~~Fixed #21961 -- Added support for database level delete options for ForeignKey.~~ [WiP] Fixed #21961 -- Added support for database level delete options for ForeignKey. Oct 7, 2025

felixxm force-pushed the db-cascade-21961 branch 7 times, most recently from f816238 to febec5c Compare October 8, 2025 11:32

LilyFirefly reviewed Oct 8, 2025

View reviewed changes

django/db/backends/base/schema.py Outdated Show resolved Hide resolved

django/db/models/deletion.py Show resolved Hide resolved

felixxm force-pushed the db-cascade-21961 branch from febec5c to 8a0c034 Compare October 9, 2025 06:47

felixxm mentioned this pull request Oct 9, 2025

Refs #21961 : Added support for database-level cascading options #16851

Closed

felixxm force-pushed the db-cascade-21961 branch 2 times, most recently from a7af053 to 42bde24 Compare October 9, 2025 08:12

jacobtylerwalls added the Django on the Med 🏖️ label Oct 9, 2025

felixxm force-pushed the db-cascade-21961 branch from 42bde24 to 70080f3 Compare October 9, 2025 09:43

jacobtylerwalls reviewed Oct 9, 2025

View reviewed changes

felixxm force-pushed the db-cascade-21961 branch 5 times, most recently from 68884c1 to 1ffc225 Compare October 9, 2025 14:12

felixxm changed the title ~~[WiP] Fixed #21961 -- Added support for database level delete options for ForeignKey.~~ [WiP] Fixed #21961 -- Added support for database-level delete options for ForeignKey. Oct 9, 2025

felixxm force-pushed the db-cascade-21961 branch 3 times, most recently from 4bc3363 to 9353da6 Compare October 10, 2025 10:34

felixxm marked this pull request as ready for review October 10, 2025 11:26

felixxm changed the title ~~[WiP] Fixed #21961 -- Added support for database-level delete options for ForeignKey.~~ Fixed #21961 -- Added support for database-level delete options for ForeignKey. Oct 10, 2025

felixxm force-pushed the db-cascade-21961 branch from 2b744df to 6bea938 Compare October 10, 2025 11:52

charettes reviewed Oct 10, 2025

View reviewed changes

felixxm force-pushed the db-cascade-21961 branch from 6bea938 to 0ef3064 Compare October 10, 2025 21:18

felixxm force-pushed the db-cascade-21961 branch from 0ef3064 to 81ea5a7 Compare October 10, 2025 21:20

felixxm force-pushed the db-cascade-21961 branch from 81ea5a7 to 47446e3 Compare October 11, 2025 17:06

felixxm force-pushed the db-cascade-21961 branch from cd45cf6 to 0664b7f Compare October 11, 2025 19:04

Added supports_on_delete_db_restrict feature flag and fixed tests.

74adb91

felixxm force-pushed the db-cascade-21961 branch from 0664b7f to 74adb91 Compare October 11, 2025 20:15

adamchainz reviewed Oct 11, 2025

View reviewed changes

		"The model cannot have both related fields with "
		"database-level and python-level on_delete variants.",

-If ``DB_*`` options are used, Django doesn't need to fetch objects into memory
-to send signals and handle cascades. However, if there are no cascades and no
-signals, then Django may take a fast-path and delete objects without fetching
-into memory. For large deletes this can result in significantly reduced memory
-usage. The amount of executed queries can be reduced, too.
+Django won’t need to fetch objects into memory when deleting them in two cases:
+. If related fields use ``DB_*`` options.
+. If there are no cascades and no delete signal receivers.
+In these cases, Django may take a fast path and delete objects without fetching
+them, which can result in significantly reduced memory usage and fewer executed
+queries.

		* models.E049: The model cannot have both related fields with
		database-level and python-level ``on_delete`` variants.

-The database variants are more efficient because they avoid fetching related
-objects, but ``pre_delete`` and ``post_delete`` signals won't be sent when
-:attr:`~django.db.models.DB_CASCADE` is used.
+These options handle deletion logic entirely within the database, using the SQL
+``ON DELETE`` clause. They are thus more more efficient than the existing
+Python-level options, as Django does not need to load objects before deleting
+them. As a consequence, the :attr:`~django.db.models.DB_CASCADE` option does
+not trigger the ``pre_delete`` or ``post_delete`` signals.

Uh oh!

Fixed #21961 -- Added support for database-level delete options for ForeignKey. #19925

Are you sure you want to change the base?

Fixed #21961 -- Added support for database-level delete options for ForeignKey. #19925

Conversation

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adamchainz Oct 11, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants