so that the ordering doesn't accidentally restrict the result set.
(Ironically, one existing test actually showed this problem, but I was too
dumb to notice the result was incorrect.)
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7761 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Avoids joining with the wrong tables when connecting select_related() tables to
the main query. This also leads to slightly more efficient (meaning less tables
are joined) SQL queries in some other cases, too. Some unnecessary tables are
now trimmed that were not previously.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7741 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Previously, if we were querying across a nullable join and then a non-nullable
one, the second join would not be a LEFT OUTER join, which would exclude
certain valid results from the result set.
This is the same problem as [7597] but for values() field specifications, so
this covers the second case where Django adds extra stuff to the select-clause.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7740 bcc190cf-cafb-0310-a4f2-bffc1f526a37
database level. Also worked around the fact that MySQL (and maybe other
backends we don't know about) cannot select from the table they're updating.
Fixed#7095.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7496 bcc190cf-cafb-0310-a4f2-bffc1f526a37
marked as erroneous. It's just more dangerous and risky, not forbidden. This
commit restores backwards compatibility there.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@7490 bcc190cf-cafb-0310-a4f2-bffc1f526a37