Opened 17 years ago

Closed 16 years ago

Last modified 13 years ago

#7110 closed (fixed)

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

Reported by: ElliottM Owned by: Jacob
Component: Uncategorized Version: dev
Severity: Keywords: qsrf-cleanup select_related foreign key
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

select_related_test.zip (3.3 KB ) - added by ElliottM 17 years ago.
App containing models.py and "runtest.py" which shows a test case.

Download all attachments as: .zip

Change History (14)

by ElliottM, 17 years ago

Attachment: select_related_test.zip added

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

comment:1 by Malcolm Tredinnick, 17 years ago

Owner: changed from nobody to Malcolm Tredinnick

comment:2 by ElliottM, 17 years ago

Summary: select_related returns incorrect results in certain cases.select_related returns incorrect results when one models has two FKS to the same model

comment:3 by ElliottM, 17 years ago

Summary: select_related returns incorrect results when one models has two FKS to the same modelselect_related returns incorrect results when one models has two ForeignKeys to the same model

comment:4 by ElliottM, 17 years ago

Summary: select_related returns incorrect results when one models has two ForeignKeys to the same modelselect_related returns incorrect results when one model has two ForeignKeys to the same model

comment:5 by Jacob, 17 years ago

Triage Stage: UnreviewedAccepted

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.

comment:6 by Jacob, 17 years ago

Owner: changed from Malcolm Tredinnick to Jacob
Status: newassigned

comment:7 by oyvind, 17 years ago

Pretty sure it is the same bug.

comment:8 by George Vilches, 17 years ago

Keywords: qsrf-cleanup added

comment:9 by Jacob, 17 years ago

milestone: 1.0

comment:10 by Malcolm Tredinnick, 16 years ago

Resolution: fixed
Status: assignedclosed

(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.

comment:11 by soroosh@…, 16 years ago

Resolution: fixed
Status: closedreopened

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

comment:12 by Jacob, 16 years ago

Resolution: fixed
Status: reopenedclosed

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

comment:13 by Jacob, 13 years ago

milestone: 1.0

Milestone 1.0 deleted

Note: See TracTickets for help on using tickets.
Back to Top