#31243: Implement set/remove/clear for non-nullable Reverse FKs
-------------------------------------+-------------------------------------
Reporter: Clayton | Owner: nobody
Daley |
Type: New | Status: new
feature |
Component: Database | Version:
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
In #31242 I note that the current implementation of `set` for non-nullable
reverse FKs is semantically incorrect and, to fix the immediate bug,
propose removing the method (as Django does for `clear` and `remove`).
However, I'd also like to make the case for implementing the full stack
(`set`/`clear`/`remove`) to support deletion. This makes sense because
I'm about to be the next in a long line of people who are duplicating the
exact same logical flow as `set` (using `delete` instead of the absent
`remove`) for non-nullable reverse FKs.
On the surface, it makes sense that a `set` would delete non-nullable
objects, but I appreciate that there are cases where forced reassignment
is desirable. However, I believe these cases are coincident with
`on_delete=PROTECT`.
Can you think of a common case where you need to preserve the related
object under full deletion but not under partial (or vice versa)? For
example, consider `House` and `Owner` (where house has one owner by FK).
If we're building a system for a county assessor, it makes sense to
preserve the `House` (and related objects) so you don't want
`owner.houses.set()` to delete the `House`. But you also don't want
`owner.delete()` (e.g. on death) to cascade to `House` either. If
`on_delete` already expresses the model-level constraint we need to
respect, the implementation is relatively easy.
If you took this opinion to its logical extreme:
- PROTECT prevents removal by reverse FK (even for nullables)
- SET_NULL (only valid when nullable) allows removal by setting to `None`
- CASCADE positively indicates that removal is allowed (and that it
should result in deletion)
The idea of forcing deletes under CASCADE is a breaking change. I think
it best reflects the model-level semantics of ON_DELETE, but am happy to
preserve backwards compatibility (i.e. sets null for nullable) if that
were the only major objection to the proposal.
--
Ticket URL: <https://code.djangoproject.com/ticket/31243>
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/055.a555c71ad653c695cebb262ca763d47b%40djangoproject.com.
