FK field caching behavior change between 1.11.x and 2.x

Django Internals ORM
1

Hi

Whilst upgrading a codebase from 1.11.x to 2.0/2.2 I noticed a weird change in behavior of FK fields when copying model instances.

At the bottom of the post there is a testcase that succeeds on 1.11.x and fails on 2.x
I think the commit that changed the behavior is bfb746f983aa741afa3709794e70f1e0ab6040b5

So my question is two fold:

  1. Is the behavior in >=2.0 correct? It seems quite unexpected.
  2. What is the recommended way to clone a model instance? To date we have been using copy() in a similar fashion to the test without issue. deepcopy seems to work fine in >=2.0 but we haven’t done too much testing yet.

Test (placed in tests/model_fields/test_field_caching_change.py):
import copy

from django.test import TestCase

from .models import Bar, Foo


class ForeignKeyCachingBehaviorTest(TestCase):
    def test_copy(self):
        foo1 = Foo.objects.create(a='foo1', d=1)
        foo2 = Foo.objects.create(a='foo2', d=2)
        bar1 = Bar.objects.create(a=foo1, b='bar1')

        bar2 = copy.copy(bar1)

        bar2.pk = None
        bar2.a = foo2

        # bar2 points to foo2
        self.assertEqual(bar2.a, foo2)
        self.assertEqual(bar2.a.id, bar2.a_id)

        # bar1 is unchanged and must still point to foo1
        # These fail on Django >= 2.0
        self.assertEqual(bar1.a, foo1)
        self.assertEqual(bar1.a.id, bar1.a_id)

which I executed via the following:

python3.6 tests/runtests.py --parallel 1 model_fields
2

Not that it helps you any, but I can confirm that I was able to replicate this behavior in Django 3.0.7, so it is a current issue.

(I did these steps manually in the shell - I was able to visually confirm that bar1.a.id == foo2.id and that bar1.a_id == foo1.id)