#21961: Add support for database-level cascading options
-------------------------------------+-------------------------------------
Reporter: Christophe Pettus | Owner: Nick
| Stefan
Type: New feature | Status: assigned
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Dylan Young):
I see what you're saying.
I still think there is value to the in-app deletion policy (without the
need to "roll your own") alongside a DB-enforced deletion policy. For
example, a very sensible scheme would be to have both models.PROTECT_DB
and models.CASCADE enabled, whereas (correct me if I'm mistaken) your
scheme *only* allows allow DO_NOTHING in combination with any `_DB`
setting, which has the nasty side-effect of suppressing signals.
This could still be done in your scheme of course (and can be done now),
but it involves either a custom migration... or a bit of hacking of the
migration system, and this creates a disparity between model definition
and model implementation in the DB, not to mention the extra coding
effort.
A context manager for bypassing the ORM deletion policy would also be a
nicety (this already exists I think, but I can't recall 100%).
Alternatively a syntax that allows ORing the `*_DB` flags with the
standard ORM `on_delete` flags could be used, but I think a separate kwarg
is cleaner.
I'm curious too if there's any significant performance gain to be had from
simulating the delete (without actually deleting) in the ORM in order to
correctly fire the signals, but letting the DB deal with the actual
deletion. This would probably mean that the signal ordering would be
slightly different (all pre-delete signals would fire, followed by all
post-delete signals).
In any case, this is actually a huge problem for Django where a small bulk
deletion (say 100 rows) can take hours, and I would be thankful for any
resolution to the problem.
--
Ticket URL: <https://code.djangoproject.com/ticket/21961#comment:18>
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/061.8d5f9077e89bdebf2abb67749f2285ed%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
