#21127: on_delete should be a required parameter for ForeignKey
-------------------------------------+-------------------------------------
Reporter: carljm | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 1.5
(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
-------------------------------------+-------------------------------------
Old description:
> This wasn't done when we added the `on_delete` feature due to concerns
> about breaking backwards-compatibility with the previous always-cascade-
> deletes behavior. But if you set aside legacy considerations, it seems
> intuitively obvious (to me anyway) that SET_NULL is a superior default
> for a nullable FK than CASCADE. And even if others might have a different
> intuition, the consequences of your intuition being wrong are far from
> symmetrical: one way you get a model instance with a null FK hanging
> around that you didn't expect to still have, the other way you get data
> loss.
>
> The trick, of course, is that changing default values is hard to do with
> a deprecation process. For a deprecation warning to catch the people it
> needs to catch, you have to warn anytime an explicit value is not
> specified. So you have to force everybody to stop relying on the default
> in order to silence the deprecation warnings, which reduces the value of
> having a new default, in the short run anyway.
>
> I think it's still worth doing for the long run, though.
>
> We could also consider doing it without a deprecation process, just a
> backwards-incompatible note in the release notes. Since the consequences
> are the opposite of data loss, that might be ok. Thoughts?
New description:
(Update: consensus below was to make `on_delete` a required argument,
rather than twiddling with its defaults.)
This wasn't done when we added the `on_delete` feature due to concerns
about breaking backwards-compatibility with the previous always-cascade-
deletes behavior. But if you set aside legacy considerations, it seems
intuitively obvious (to me anyway) that SET_NULL is a superior default for
a nullable FK than CASCADE. And even if others might have a different
intuition, the consequences of your intuition being wrong are far from
symmetrical: one way you get a model instance with a null FK hanging
around that you didn't expect to still have, the other way you get data
loss.
The trick, of course, is that changing default values is hard to do with a
deprecation process. For a deprecation warning to catch the people it
needs to catch, you have to warn anytime an explicit value is not
specified. So you have to force everybody to stop relying on the default
in order to silence the deprecation warnings, which reduces the value of
having a new default, in the short run anyway.
I think it's still worth doing for the long run, though.
We could also consider doing it without a deprecation process, just a
backwards-incompatible note in the release notes. Since the consequences
are the opposite of data loss, that might be ok. Thoughts?
--
Comment (by carljm):
That looks to me like the thread consensus (and I agree with it).
--
Ticket URL: <https://code.djangoproject.com/ticket/21127#comment:19>
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/064.232cd324397add47dad38376bb0e8955%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
