Hello, > On 15 Oct 2021, at 08:49, Barry Johnson <bajohn...@epicor.com> wrote: > > Instead of resolving this difference in keys by executing: > setattr(self, field.attname, obj.pk) > We believe it should instead: > setattr(self, field.name, obj)
For anyone reading this, this code is https://github.com/django/django/pull/13589/files#diff-1c8b882c73bfda668d5451d4578c97191b0ebc0f088d0c0ba2296ab89b428c44R939 <https://github.com/django/django/pull/13589/files#diff-1c8b882c73bfda668d5451d4578c97191b0ebc0f088d0c0ba2296ab89b428c44R939> I think the proposed change is correct. I reviewed this pull request and related ticket, as well as prior art in the area, and I'm not seeing a reason for assigning just the PK (= PK set, related cache not set) rather than the entire object (= PK and related cache both set). Disclaimer — while I was involved in this area long ago, I didn't follow what happened after commit 5980b05c, where the "prevent data loss with unsaved related objects" checks were moved from the moment a related object is assigned to the moment the object is saved. I reviewed Carlton's wontfix, which made sense to me, to understand why we didn't reach the same conclusion. Carlton thinks the code has been here for a very long time and would be tricky to touch; I believe that we're only touching a line introduced in 519016e5, 2.5 years ago, which doesn't feel _that_ old to me. Hope this helps! -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3F76E6A2-439B-4510-AF32-F9ED766A34CB%40polytechnique.org.
