Support lookup separators in ModelAdmin.list_display
|Reported by:||mrts||Owned by:||nobody|
|Cc:||ales.zoulek@…, zachborboa@…, olivier.dalang@…||Triage Stage:||Accepted|
|Has patch:||yes||Needs documentation:||yes|
|Needs tests:||yes||Patch needs improvement:||no|
As with #3400, supporting the
__ lookup separator in
ModelAdmin.list_display is useful as it avoids calling
__unicode__ bluntly, giving users more control over the output:
- display several fields from the same related model,
- as listed in #3400, traverse several levels of relations.
One could argue that most of this can be achieved with
__unicode__ by cramming the information to its output.
However, there's a larger problem with deferred fields (deferring is exemplified in this comment) -- namely, that couples admin code to the implementation of
__unicode__ in related models. That is, knowledge of what fields are referred to in
__unicode__ is required to write proper deferred statements.
A case to illustrate how changes in
__unicode__ can have dramatic, unintentional impact:
- assume the related objects are large and complex,
- to keep the admin changelist view snappy, the developer looks which fields are referred to in their
__unicode__and writes the
ModelAdmin.queryset()method correspondingly, selecting only these fields with
- a single query is all that is needed to display the data in changelist view, admin is snappy, there is much rejoicing,
- a second person keeps hacking at the related models, unknowing the impact changes to
__unicode__could have to admin, adds another field to it,
- suddenly rendering the changelist results in
nqueries, each of which pulls in the whole object.
All that can be avoided with explicit
Change History (16)
comment:1 Changed 7 years ago by
|Patch needs improvement:||unset|
|Triage Stage:||Unreviewed → Accepted|
comment:2 Changed 7 years ago by