id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux 10743,Support lookup separators in ModelAdmin.list_display,mrts,Tom Carrick,"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 [http://code.djangoproject.com/ticket/10712#comment:3 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.",New feature,closed,contrib.admin,dev,Normal,fixed,"efficient-admin, list_display",ales.zoulek@… zachborboa@… olivier.dalang@… Ofer Nave Adam Johnson Egor R Nina Menezes Tom Carrick,Ready for checkin,1,0,0,0,0,0