Opened 17 years ago
Closed 17 years ago
#7526 closed (duplicate)
Query Set Refactor handling of INNER JOINs
| Reported by: | khoobks | Owned by: | George Vilches |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Keywords: | query set refactor order_by inner join | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Hi,
The best way for me to explain the issue I have discovered is to run the test case provided with this ticket. The test case is a modification of the many_to_one test case that comes with Django. I have commented out the "unnecessary" bits for clarity.
The problem that I am reporting is that due to the way that the ordering is expressed in the example, a join to the related table is necessary.
When performing any query on this model (except a count) an INNER JOIN is used in the SQL command. If we are trying to get all rows (from a table that contains some rows) using "all()", an INNER JOIN will be performed to the related table which, in the example contains no rows. This results in the "all()" function returning an empty query set which is incorrect. I think.
Regards
Attachments (1)
Change History (4)
by , 17 years ago
comment:1 by , 17 years ago
| Component: | Core framework → Database wrapper |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
Can you please check the patch filed against #7512? I tried it out, and it appears to resolve this issue as well. If so, let's close this ticket as a dupe, and if you have anything further that this ticket doesn't yet cover, you can add it to the comment thread on that ticket.
comment:2 by , 17 years ago
I agree. I think mine is a dupe.
I has a look at #7512 and that seemed to sort out the issue.
Thanks
Test case illustrating the issue.