It's a lot more efficient, for one.
select_related() generates more code to query the database. It also
goes as "far as possible", so if the blog has a lot more relationships
to it or if the entries have a lot more relationships to them, then
select_related would be pretty inefficient especially since it already
knows the exact object for the blog. If you already have the
information, then why query the database for it? Why not just cache
it right away?
Other reasons it's different...
b = Blog.objects.get(id=1)
for entry in b.entry_set.all():
entry.blog is b # True
Ok, so that might not be a big deal in most cases, but imagine the
blog object does some calculations that each blog entry might want to
know about. (This is the case in my application, but with different
models). If each blog is a fresh object from the database, then this
information would have to be recalculated for each object accessing
the original blog. But if the blog caches it and it's the same blog
every time, then everything's a lot faster. Just a code example that
might help explain what I was trying to say:
b = Blog.objects.get(id=1)
for entry in b.entry_set.all():
calculated = entry.blog.do_some_heavy_calculation()
entry.handle(calculated)
The reason for not just using the original b object? Well if you're
passing your list of entries to a view (and don't want to pass the
blog object as well because - well, why should you have to?), then
this situation is very real.
Another reason... select_related() isn't needed here and shouldn't be
required to be used here. It's possible to get the same result via
simple caching. select_related() is something entirely different.
And the last reason this is different from select related:
b = Blog.objects.get(id=1)
for entry in b.entry_set.all():
entry.blog is b # There is no reason that this should not be
True
It makes sense for that to be True. For people unaware of what's
going on, that should be True. For people assuming it's True, it
should be. If the information's there for it to be True, and it's
possible for it to be True, then shouldn't it be?
That's why it's different.
All tests still pass with the changes included.
I wrote test cases.
I added documentation.
It's ready to be included.... just needs the okay.
On Jan 29, 10:51 am, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> On 1/28/07 8:42 PM, [EMAIL PROTECTED] wrote:
>
> > i just wanted to spark some discussion of #3369. i implemented it and
> > would like to see it get included.
>
> > here's an example of what reverse caching of foreign keys would mean:
>
> > b = Blog.objects.get(id=1)
> > for entry in b.entry_set.all():
> > entry.blog # No database access required.How does this differ from
> > select_related()?
>
> Jacob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
