#16715: Wrong JOIN with nested null-able foreign keys
-------------------------------------+-------------------------------------
Reporter: sebastian | Owner: nobody
Type: Bug | Status: new
Milestone: | Component: Database layer
Version: 1.3 | (models, ORM)
Resolution: | Severity: Release blocker
Triage Stage: Accepted | Keywords: join, values,
Needs documentation: 0 | nested, foreign key, null-able
Patch needs improvement: 1 | Has patch: 1
UI/UX: 0 | Needs tests: 1
| Easy pickings: 0
-------------------------------------+-------------------------------------
Changes (by sebastian):
* severity: Normal => Release blocker
Comment:
No comments? Let me reiterate why I think this is a critical bug.
The documentation for `select_related` does not mention in any way that
the resulting queryset will differ from the one without `select_related`
attached. This is also the expected behavior. Unfortunately, this does not
match reality. Either the documentation should be changed to reflect the
observed behavior (if it is indeed the intended behavior) or the observed
behavior should be fixed to match the documentation.
The same is true for the documentation of `values`. While the change in
behavior with regard to many-to-many relations is only natural and
accordingly documented (multiple rows are returned, one for each
referenced combination of values), the behavior currently exhibited with
nullable foreign keys is surprising. While this might be reflected by a
subtle change in documentation (something like "rows with nulled foreign
keys are discarded from the result"), this would still fail to explain the
inconsistent behavior between one-hop foreign key lookups and two-hop
foreign key lookups, and the dependence on the order of arguments to
`values`.
Finally, the observed (wrong) behavior might be only one symptom of a
deeper problem within the query generator in Django. I am not familiar
enough with how the query generator works in detail to verify or disprove
that, but it might be that with multi-table joins are wrong the current
way queries are created right now, especially the way the decision between
INNER JOIN and LEFT OUTER JOIN is made.
Since these arguments feel strong enough to me to justify further insight
into the matter, I am changing the severity to release blocker. If the
problem cannot be fixed, it should at least be documented in
`select_related` and `values`.
--
Ticket URL: <https://code.djangoproject.com/ticket/16715#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
