select_related returns incorrect results when one model has two ForeignKeys to the same model

[ElliottM]

This started occurring just after the qs-rf branch was merged into trunk.

Essentially, my Connection models has two separate FKs to the Port model (called start and end), the Port model has a FK to the device model, and the Device model has a FK to the building model.

When I want to get a list of all connections that start and end in the same building, I do the following:

Connection.objects.filter(start__device__building=building_name, end__device__building=building_name)

This works correctly for the most part. However, if I add .select_related() onto the end of the line, it all goes wrong. The following is the output from runtest.py in the attachment, which should show the problem:

>>> from test import runtest
Begin list of normal filter
10      FROM    router/4        TO      switch/7
11      FROM    switch/7        TO      server/1
(end list)



Begin list of filter using select_related
10      FROM    switch/4        TO      switch/7
11      FROM    server/7        TO      server/1
(end list)

As you can see, in the first list, the start of the first connection is device "router", port 4 and the end is device "switch", port 7. When the exact same query is done with select_related on the end, the port numbers are the same, but the start device has for some reason been changed to be equal to the end device. From what I read in the documentation, select_related should not affect the output at all, so I believe this must be a bug.

Attached is my whole test app where you can see for yourself what is happening.

[ElliottM]

App containing models.py and "runtest.py" which shows a test case.

[Jacob]

See also #7125; I suspect this is the same bug but I'm not sure so I'm not going to mark either a duplicate, yet.

[oyvind]

Pretty sure it is the same bug.

[Malcolm Tredinnick]

(In [7778]) Fixed handling of multiple fields in a model pointing to the same related model.

Thanks to ElliotM, mk and oyvind for some excellent test cases for this. Fixed #7110, #7125.

[soroosh@…]

The problem still exists, and can be triggered using a more complicated model like the one in #8106

[Jacob]

#8106 is slighty different, actually, so let's take that discussion over there.

[Jacob]

Milestone 1.0 deleted