Django

Code

Changeset 6968

Show
Ignore:
Timestamp:
12/22/07 05:16:21 (1 year ago)
Author:
mtredinnick
Message:

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).

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved
  • django/branches/queryset-refactor/tests/regressiontests/queries/models.py

    r6962 r6968  
    270270[<Item: one>] 
    271271 
     272# FIXME: This is difficult to fix and very much an edge case, so punt for now. 
     273# # This is related to the order_by() tests, below, but the old bug exhibited 
     274# # itself here (q2 was pulling too many tables into the combined query with the 
     275# # new ordering, but only because we have evaluated q2 already). 
     276# >>> len((q1 & q2).order_by('name').query.tables) 
     277# 1 
     278 
    272279>>> q1 = Item.objects.filter(tags=t1) 
    273280>>> q2 = Item.objects.filter(note=n3, tags=t2) 
     
    378385[<Ranking: 1: a3>, <Ranking: 2: a2>, <Ranking: 3: a1>] 
    379386 
     387# If we replace the default ordering, Django adjusts the required tables 
     388# automatically. Item normally requires a join with Note to do the default 
     389# ordering, but that isn't needed here. 
     390>>> qs = Item.objects.order_by('name') 
     391>>> qs 
     392[<Item: four>, <Item: one>, <Item: three>, <Item: two>] 
     393>>> len(qs.query.tables) 
     3941 
     395 
    380396# Ordering of extra() pieces is possible, too and you can mix extra fields and 
    381397# model fields in the ordering.