#16715: Wrong JOIN with nested null-able foreign keys
-------------------------------------+-------------------------------------
Reporter: sebastian | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: SVN
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: join, values, | Needs documentation: 0
nested, foreign key, null-able | Patch needs improvement: 0
Has patch: 1 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by akaariai):
Thank you very much for the cleanup. I did that mistake on my work
computer, and can't (or rather will not) access it before friday. If trac
could warn that 'your patch does not apply cleanly', that would be a great
feature.
About doing the join promotion only at the time when the query is about to
be executed. I have been thinking about something similar to that, it is
IMO the right approach. Except I think we should begin with the assumption
that all joins are LEFT JOINS and promote (unpromote?) them to INNER JOINS
only when we can be sure it is safe. I can't think of a situation where it
would be wrong to use a LEFT JOIN instead of INNER JOIN in Django's query
generator. The other direction is certainly dangerous, there have been,
and still is too numerous tickets about that.
The reason for doing promotion in reversed direction is that I believe
getting the joins perfectly correctly is actually NP-complete (very
similar to SAT). So, I believe we will never get perfect results. If we
start from INNER JOINS and try to approach from above the perfect
situation, we will have a lot of bugs to fix. But if we instead do it in
the other direction, approaching from below, we only have some
optimization problems ahead. If there is some way to do this perfectly, at
least we haven't found it yet.
I have been working with the add_q code, and the query construction is
very anal about the structure of the where three passed in. And the
problem is always that it thinks INNER JOIN is the right thing to do when
it is not. When looking at the promotion code and fixes to it, it is
evident that the current approach of fixing the problems one at a time
will not carry much further.
It might be that I am wrong about the NP-completeness, and I wouldn't be
surprised if there are situations where we must use INNER JOINS. Still,
reversing the promotion direction should result in less bugs.
--
Ticket URL: <https://code.djangoproject.com/ticket/16715#comment:16>
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.
