Admin generates a query burst on ForeignKey with null = True

[piro]

When the The admin loads a list of objects to display the change list, it is supposed to ​use select_related() to fetch ForeignKey fields in the display list.

Because it uses the form select_related() without the filed name, ​the records are not fetched if the property has null=True. This generates a burst of up of 100 query to display the admin page for such a model.

Attached there is a preliminary patch to fix the issue. It is probably to be improved as it doesn't kick in if the model is configured with list_select_related=True or if select_related() was already called on the query.

[Daniel Roseman]

I propose an extended syntax for list_select_related, to allow it to accept a list/tuple of field names, which is passed through as parameters to the query's select_related() call. This allows the developer to specify explicitly which relations to follow, as in a normal query.

Attached patch (which isn't displaying in Trac for some reason, but is a valid svn diff on download) adds this, plus tests and docs. Also fixes an additional issue with list_select_related in that it doesn't follow OneToOneField relations, which are supported in select_related calls.

[Ilya Semenov]

danielr's patch makes perfect sense.

[Brillgen Developers]

An alternative syntax which allows to at least limit the depth of the select related. Simple change would be to make list_select_related=<number> where <number> is the depth parameter for select_related.
Danielr's suggestion is also greate and can be implemented as another field...suggestion: list_select_related_fields

[patchhammer]

14396_list_select_related.patch fails to apply cleanly on to trunk

[Daniel Roseman]

Updated patch which applies against trunk.

[Erik Wognsen]

What is the status of this ticket?

I think the idea of allowing lists/tuples for list_select_related is good and I would love to see this feature included.

[Tim Graham]

Duplicate of #19080 which has been fixed.