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

1 files changed, 7 insertions, 1 deletions

diff --git a/tests/regressiontests/queries/models.py b/tests/regressiontests/queries/models.py
index d7c8fba9c6..a3e5561b86 100644
--- a/tests/regressiontests/queries/models.py
+++ b/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
+
 """}