#28147: Saving parent object after setting on child leads to unexpected data
loss
-------------------------------------+-------------------------------------
Reporter: Erwin Junge | Owner: robinh00d
Type: Bug | Status: closed
Component: Database layer | Version: master
(models, ORM) |
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Jon Dufresne):
Thanks. I'm happy to fix my own code to assign to the FK instead of the FK
ID, that is no problem on my end. So no need to revert.
However, I interact with the FK ID as a readonly field all the time and
think it is fine practice to do so. So I'm not sure I fully agree with
linked note. If one simply wants to check the FK is not `NULL`, using the
`_id` field can potentially avoid an unnecessary query. In that use case,
I think the interaction is fine. For example, the following can avoid a
query:
{{{
if child.parent_id:
# has parent
}}}
Perhaps the `_id` field should be improved and enforced to be a readonly
property. If one tries to assign to a `_id`, an error would be thrown. If
one reads from the field, the field is read as normal. This would be
similar to how the many-to-many field handles direct assignment. At the
very least, it would avoid project bugs due to silently restored FKs from
this change in behavior.
--
Ticket URL: <https://code.djangoproject.com/ticket/28147#comment:17>
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.f64f72af6a44e2bffdc9456c67300b36%40djangoproject.com.
