Does anyone else have any thoughts on this? On Jan 29, 4:25 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > 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 django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
