Opened 11 years ago
Closed 11 years ago
#20583 closed Cleanup/optimization (fixed)
Make setup_joins() the primary API for join generation
Reported by: | Anssi Kääriäinen | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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).
Change History (3)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Summary: | Make get_path_info() the primary API for join generation → Make setup_joins() the primary API for join generation |
---|---|
Version: | 1.5 → master |
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.
comment:3 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Should the title be: Make "setup_join() the primary API for join generation" instead?