Split Query add_filter and setup_joins into smaller methods for easier subclassing

[Fabio Corneti]

Projects such as ​Django Multilingual use an highly customized django.db.models.sql.Query subclass to support advanced custom filters; in order to do so we need to copy the entire setup_joins and add_filter methods and apply our custom code inside them.

The proposed patch splits add_filter and setup_joins in slightly smaller methods, allowing subclasses to inject custom code into filtering procedures in an easier and more maintainable way.

Tested with Django trunk using the standard test suite.

[Alex Gaynor]

I haven't had a chance to review this patch in any detail, but you'll probably want to apply whatever changes you make here to the OracleQuery class as well.

[Fabio Corneti]

Replying to Alex:

I haven't had a chance to review this patch in any detail, but you'll probably want to apply whatever changes you make here to the OracleQuery class as well.

The patch splits the setup_joins and add_filter methods which are not overridden by OracleQuery.

[Alex Gaynor]

Ah, ok.

[Malcolm Tredinnick]

setup_joins(), in particular, is very performance critical. I originally wrote a few versions that split out the inner loops, but the difference in all the function calls if very noticeable. I'm not particularly inclined to make this change at the moment, since it's not really clear that poking at the internals of setup_join() is a good plan. Your change is predicated on the assumption that django-multilingual's approach is a good idea (somehow adding extra joins without being explicit) and I'd rather this was done through more natural filter usage. I think this really needs to first be a design discussion about the approach to constructing the query, since there are alternative approaches. It really is one method for a reason.

It certainly may well be possible to add extra hooks into the join setup and/or filter creation and it might be possible to split up add_filter(), although, again, it sounds fragile to inject into the middle of that, since it's a fairly self-contained operation.

Therefore, this is a case of first working out the problems you are trying to solve and all of use coming up with a solution that meets all requirements, rather than going straight to this particular solution implementation, which has some drawbacks will real impact on the common cases. Going to wontfix for now for those reasons.