#21961: ForeignKey.on_delete supports database-level cascading options
----------------------------------------------+-------------------------
Reporter: Xof | Owner: nobody
Type: New feature | Status: new
Component: Database layer (models, ORM) | Version: 1.7-alpha-1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------------------+-------------------------
Per a discussion on -developers, this ticket is to document this proposed
new feature.
The general idea is to allow developers to specify that the database
itself, rather than Django, should implement foreign key constraints where
possible. The database can be considerably more efficient, and often can
avoid locking situations, in a way that the Django backend can't.
The proposal is to add a models.CASCADE_DB, models.SET_NULL_DB,
models.PROTECT_DB constants. These specify that the appropriate
functionality is to be implemented in the database if the database
supports it; otherwise, they are implemented in the Django core as now.
Some potential design issues with proposed solutions:
1. It is not an error to specify the _DB version with a database that
doesn't support it. Instead, you get the non-_DB version.
2. The _DB version does not fire signals; this will need to be documented.
3. If a model A references a model B using CASCADE_DB, but model B
references model C using regular CASCADE, a deletion of A won't cascade
all the way to C. This needs to be documented. Another possibility is to
make this an error condition and have model validation fail, but that
seems excessive.
4. The _DB version is disallowed on generic foreign keys, because that way
madness lies.
5. The implicit foreign key created from child to parent in model
inheritance is never the _DB version. This is a shame, but there are two
issues:
a) Since it's created implicitly, there's no place to put it.
b) Even if we extended the mechanism to allow manual specification of
the key, deleting the parent wouldn't automatically delete the child.
--
Ticket URL: <https://code.djangoproject.com/ticket/21961>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/046.5bd99788ce763b2418440bc162ac54b9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.
