queryset-refactor: Added a couple of tests to demonstrate table handling in order_by() situations. One is known to fail (and commented out for now).

git-svn-id: http://code.djangoproject.com/svn/django/branches/queryset-refactor@6968 bcc190cf-cafb-0310-a4f2-bffc1f526a37

1 files changed, 16 insertions, 0 deletions

diff --git a/tests/regressiontests/queries/models.py b/tests/regressiontests/queries/models.py
index 7e1c8d31ed..e1d7c4a258 100644
--- a/tests/regressiontests/queries/models.py
+++ b/tests/regressiontests/queries/models.py
@@ -269,6 +269,13 @@ Bug #2253
 >>> (q1 & q2).order_by('name')
 [<Item: one>]
 
+# FIXME: This is difficult to fix and very much an edge case, so punt for now.
+# # This is related to the order_by() tests, below, but the old bug exhibited
+# # itself here (q2 was pulling too many tables into the combined query with the
+# # new ordering, but only because we have evaluated q2 already).
+# >>> len((q1 & q2).order_by('name').query.tables)
+# 1
+
 >>> q1 = Item.objects.filter(tags=t1)
 >>> q2 = Item.objects.filter(note=n3, tags=t2)
 >>> q3 = Item.objects.filter(creator=a4)
@@ -377,6 +384,15 @@ Bug #2076
 >>> Ranking.objects.all().order_by('rank')
 [<Ranking: 1: a3>, <Ranking: 2: a2>, <Ranking: 3: a1>]
 
+# If we replace the default ordering, Django adjusts the required tables
+# automatically. Item normally requires a join with Note to do the default
+# ordering, but that isn't needed here.
+>>> qs = Item.objects.order_by('name')
+>>> qs
+[<Item: four>, <Item: one>, <Item: three>, <Item: two>]
+>>> len(qs.query.tables)
+1
+
 # Ordering of extra() pieces is possible, too and you can mix extra fields and
 # model fields in the ordering.
 >>> Ranking.objects.extra(tables=['django_site'], order_by=['-django_site.id', 'rank'])