#13902: When using a ManyToMany in list_filter, results may apper more than once
-------------------------------------------+--------------------------------
          Reporter:  rasca                 |         Owner:  rasca              
                     
            Status:  new                   |     Milestone:                     
                     
         Component:  django.contrib.admin  |       Version:  SVN                
                     
        Resolution:                        |      Keywords:  admin change_list 
list_filter manytomany
             Stage:  Accepted              |     Has_patch:  1                  
                     
        Needs_docs:  0                     |   Needs_tests:  0                  
                     
Needs_better_patch:  0                     |  
-------------------------------------------+--------------------------------
Changes (by russellm):

  * stage:  Unreviewed => Accepted

Comment:

 On the whole, this looks good. Don't worry about the diff display problem
 -- this is a known issue with Trac; it has something to do with patches
 that have "No newline at end of file" lines in them. This doesn't actually
 pose a problem applying the patch, but Trac won't display the patch at
 all. Don't get too hung up on this problem.

 As for the patch: a couple of fairly minor fixes:

  * Constants are in ALLCAPS, variables shouldn't be. Use is_distinct, not
 DISTINCT.
  * Rather than using unittest.TestCase and manually tearing down the test,
 it will be faster to use Django's TestCase and use the rollback facilities
 that it provides.

 ... and one bigish issue:

 I'm not convinced that finding more than one '!__' in a list filter is
 enough of a qualifier. For example, !__exact is an implied comparison so
 multiple_m2m__id=1 will only have 1 !__, but will be prone to duplicates.

 That said, I'm wondering if there's an argument to be made that distinct()
 should always be applied. There will be a inefficiency in the query if we
 always apply distinct(), but the cases where it isn't required should be
 able to optimize out the distinct() at the SQL level.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/13902#comment:2>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Reply via email to