On Tue, Mar 23, 2010 at 10:21 AM, Vinicius Mendes | meiocodigo.com <vbmen...@gmail.com> wrote: > integrated to the framework. I think the queryset should keep track of > it self. It knows what is the filter, so why can't it negate this > filter?
Given an already-existing QuerySet which has already had all the filters applied, there's really no way to do this. The reason is that there's so much more that can be done to a QuerySet than just calls to filter(); for example, calls to extra() may have added additional raw SQL in the SELECT or WHERE clauses, and the ORM doesn't have any way to work out how to negate arbitrary user-supplied SQL. The WHERE clause itself is represented on the Query object by an instance of django.db.models.sql.where.WhereNode, which is actually a tree structure with each node representing part of the WHERE clause. Each node in that tree does know whether it's negated or not (and hence whether to use a NOT on the constraint each node expresses), but walking that tree and figuring out which nodes you'd want to negate would be difficult to say the least, and still wouldn't work on a QuerySet which had been affected by something like extra(). So about the only way to do this is to collect the filter arguments in advance *without* applying them to the QuerySet, and then use either exclude() or negated Q objects to ensure you get a "negated" query. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
