Support lookup separators in ModelAdmin.list_display

[mrts]

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 only(),
• 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 n queries, each of which pulls in the whole object.

All that can be avoided with explicit __ support.

[Rilt]

Added a patch, but would definitely like someone to look at it and comment. The basic jist of what I did was add an additional check for any strings with __ in them, indicating a field spanning a relationship, and then looping through each relationship until the proper attribute was grabbed. Then in the admin validation, there is a recursive function which accurately checks that the field exists and is not a ManyToMany.

[James Bennett]

1.2 is feature-frozen, moving this feature request off the milestone.

[Jacob]

Milestone 1.4 deleted

[Aymeric Augustin]

Added a patch, but would definitely like someone to look at it and comment. The basic jist of what I did was add an additional check for any strings with __ in them, indicating a field spanning a relationship, and then looping through each relationship until the proper attribute was grabbed. Then in the admin validation, there is a recursive function which accurately checks that the field exists and is not a ManyToMany.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Aymeric Augustin]

If I understand correctly, the goal of this ticket is to enable Django to automatically optimize the queryset for building the admin changelist by adding appropriate fields to select_related() and only().

But that can't be done automatically as soon as someone puts a callable in display_list. So we're back to square 1, except Django pretended that it could handle the optimization automatically, and failed at that.

In my opinion that would be worse that just telling the user to write an appropriate get_queryset. For this reason (and also considering limited demand for this feature over the last five years) I'm going to reject this ticket.

[Aymeric Augustin]

I'm going to reopen this ticket because I disagree with my 19-month-ago-former-self.

My present-day-self keeps trying to write:

    list_display = ['foo__bar']

and being mad at Django that it doesn't work.

We could limit that syntax to relation fields and not support calling methods on the target model if that helps. It would still solve 95% of the problem.

[Ofer Nave]

I'm eager to have this, and am surprised that it hasn't happened after 13 years.

In the meantime, I'm relying on this very small package which implements a version of this feature:

​https://github.com/PetrDlouhy/django-related-admin/