Opened 14 years ago
Closed 11 years ago
#14396 closed Cleanup/optimization (duplicate)
Admin generates a query burst on ForeignKey with null = True
Reported by: | piro | Owned by: | Daniel Roseman |
---|---|---|---|
Component: | contrib.admin | Version: | 1.2 |
Severity: | Normal | Keywords: | admin database performance |
Cc: | semenov@…, Brillgen Developers, erik.wognsen@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
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.
Attachments (4)
Change History (14)
by , 14 years ago
Attachment: | django-admin-query-burst.patch added |
---|
comment:1 by , 14 years ago
Keywords: | admin added; qdmin removed |
---|
by , 14 years ago
Attachment: | 14396_list_select_related.diff added |
---|
by , 14 years ago
Attachment: | 14396_list_select_related.patch added |
---|
comment:2 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Triage Stage: | Unreviewed → Accepted |
comment:4 by , 14 years ago
Cc: | added |
---|
comment:5 by , 14 years ago
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
comment:6 by , 14 years ago
Easy pickings: | unset |
---|---|
Patch needs improvement: | set |
Severity: | → Normal |
Type: | → Uncategorized |
14396_list_select_related.patch fails to apply cleanly on to trunk
by , 14 years ago
Attachment: | 14396_list_select_related2.patch added |
---|
comment:7 by , 14 years ago
Patch needs improvement: | unset |
---|
Updated patch which applies against trunk.
comment:8 by , 13 years ago
Type: | Uncategorized → Cleanup/optimization |
---|
comment:9 by , 13 years ago
Cc: | added |
---|---|
UI/UX: | unset |
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.
comment:10 by , 11 years ago
Resolution: | → duplicate |
---|---|
Status: | assigned → closed |
Duplicate of #19080 which has been fixed.
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.