QuerySet.complex_filter() chokes on custom Q objects (with add_to_query() method)

[Johannes Dollinger]

To reproduce, try:

class DoNothingQ:
    def add_to_query(self, query, aliases):
        pass

MyModel.objects.complex_filter(DoNothingQ())

A side effect: My patch prevents builtin Q objects from being wrapped in another Q object when passed to complex_filter(). I'm not sure that's ok.

The cause ist the same as in ​http://groups.google.com/group/django-users/msg/3e6d910eacb8b542.

[Malcolm Tredinnick]

The patch looks fine. complex_filter() is a bit of an ugly method, though, and definitely not part of the public API, so I'm going to leave out the test. We'll add tests when we fix limit_choices_to, but I'm not sure locking down the behaviour of complex_filter() just yet is the right thing to do. Non-internal code should really only be calling filter() and exclude() (or calling .query.add_q() directly, I guess).

[Malcolm Tredinnick]

(In [7766]) Fixed #7312 -- Fixed handling of custom Q-like objects in QuerySet.custom_filter().

This is pretty much internal-use-only code, so doesn't affect public API at
all, but it's nice to be able to handle things properly in any case. Patch from
emulbreh.

[Jacob]

Milestone 1.0 deleted

[Mikhail Podgurskiy]

Seems broken again in django 1.6.1

*** AttributeError: DoNothingQ instance has no attribute '__getitem__'

this happens b/c we lost in django.db.models.sql.query.Query.add_q method

if hasattr(q_object, 'add_to_query'):
    # Complex custom objects are responsible for adding themselves.
    q_object.add_to_query(self, used_aliases)
else:
   ...

[Tim Graham]

I'm not sure the example in the ticket is valid anymore. add_to_query is not a documented API. Could you clarify? There seems to be a typo in your comment: "we lost in django.db.models.sql.query.Query.add_q method" -- I'm not sure what that means.

[Anssi Kääriäinen]

I created a separate ticket for this, see #21696.