Make setup_joins() the primary API for join generation

[Anssi Kääriäinen]

Currently the ORM has two different code paths for generating joins. First, there is setup_joins() which uses internally names_to_path() which again uses get_path_info(). However some other parts of the ORM use directly field's get_joining_columns() (select_related descent in the compiler, joining of parent models to the query).

The idea is to use setup_joins() in all cases. This would unify the way joins are generated and thus ensure things work even if one needs to have weird definitions of get_path_info() and get_joining_columns() (needed for example by GenericRelation which works backwards to normal join fields).

[Simon Charette]

Should the title be: Make "setup_join() the primary API for join generation" instead?

[Anssi Kääriäinen]

When starting to write this the idea was really to say that get_path_info() should get to decide how joins are created, the field's get_joining_columns() should not be called directly.

But you are right, the ORM changes required are to use setup_joins() directly.

[Anssi Kääriäinen <akaariai@…>]

In aa22cbd51aa6cb35fc658dd704948a18b27d1981:

Fixed #20583 -- ORM always uses setup_joins() for join generation

There were a couple of places which used Query.join() directly. By
using setup_joins() in these places the code is more DRY, and in
addition there is no need to directly call field.get_joining_columns()
unless the field is the given join_field from get_path_info(). This
makes it easier to make sure a ForeignObject subclass generates joins
correctly in all cases.