Fixed #7181 -- when ordering by a potentially NULL field, use a left-outer join

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

django/db/models/sql/query.py

@@ -610,6 +610,10 @@ class Query(object):
         alias = joins[-1]
         col = target.column
 
+        # Must use left outer joins for nullable fields.
+        for join in joins:
+            self.promote_alias(join)
+
         # If we get to this point and the field is a relation to another model,
         # append the default ordering for that model.
         if field.rel and len(joins) > 1 and opts.ordering:

tests/regressiontests/queries/models.py

@@ -499,7 +499,7 @@ FieldError: Infinite loop caused by ordering.
 # Ordering by a many-valued attribute (e.g. a many-to-many or reverse
 # ForeignKey) is legal, but the results might not make sense. That isn't
 # Django's problem. Garbage in, garbage out.
->>> Item.objects.all().order_by('tags', 'id')
+>>> Item.objects.filter(tags__isnull=False).order_by('tags', 'id')
 [<Item: one>, <Item: two>, <Item: one>, <Item: two>, <Item: four>]
 
 # If we replace the default ordering, Django adjusts the required tables
@@ -762,5 +762,11 @@ Bug #7076 -- excluding shouldn't eliminate NULL entries.
 >>> Tag.objects.exclude(parent__name=t1.name)
 [<Tag: t1>, <Tag: t4>, <Tag: t5>]
 
+Bug #7181 -- ordering by related tables should accomodate nullable fields (this
+test is a little tricky, since NULL ordering is database dependent. Instead, we
+just count the number of results).
+>>> len(Tag.objects.order_by('parent__name'))
+5
+
 """}