Caching of related objects can be improved

[Ned Batchelder (ned@…]

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

Explanation:

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.

[ned@…]

The patch!

[Jacob]

How does this differ from select_related (​http://www.djangoproject.com/documentation/db_api/#selecting-related-objects)? I'm fairly sure that select_related already does this.

[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!

[Adrian Holovaty]

(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