Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1548 closed enhancement (fixed)

Caching of related objects can be improved

Reported by: Ned Batchelder (ned@… Owned by: Adrian Holovaty
Component: contrib.admin Version:
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


This is an improvement to related object caching on the trunk.


When using getters, an object attribute is used to cache the result so the database is not consulted on a subsequent call. For example:

   c.get_poll()  # Hits the db
   c.get_poll()  # doesn't, reads the cache attribute

When getting a list of related objects, no record is made of the object that spanwed them:

   c = p.get_choice_list()
   c.get_poll()  # Hits the db

This patch changes get_FOO_list() to pre-cache the parent object so that the get_poll call wouldn't have to hit the db. In the example, p has already been loaded, and because c was created from it, we know that it is the answer to get_poll().

I haven't investigated how this would apply to the magic-removal branch.

Attachments (1)

patch.txt (1.4 KB) - added by ned@… 12 years ago.
The patch!

Download all attachments as: .zip

Change History (4)

Changed 12 years ago by ned@…

Attachment: patch.txt added

The patch!

comment:1 Changed 12 years ago by Jacob

How does this differ from select_related ( I'm fairly sure that select_related already does this.

comment:2 Changed 12 years ago by Adrian Holovaty

Jacob -- No, select_related doesn't already do this, because select_related doesn't apply in the situation of p.get_choice_list().

Thanks for the patch, Ned!

comment:3 Changed 12 years ago by Adrian Holovaty

Resolution: fixed
Status: newclosed

(In [2574]) Fixed #1548 -- Improved caching of related objects, so when clist = poll.get_choice_list(), each choice in clist has its poll cache filled. Thanks, Ned Batchelder

Note: See TracTickets for help on using tickets.
Back to Top