On Monday, December 13, 2010 11:20:21 AM UTC, Scoox wrote:Hi Daniel, thanks for your answer. Sorry, cmp should be c. I tried to only give the import parts to make it more readable, but I made a mistake there. The model code is pretty standard, except for one function:
isEditable=0 login=0 def editable(self): if self.login==0: return False else: if self.isEditable!=0: return self.isEditable if self==self.login.get_profile(): self.isEditable=True for o in self.offer_set.all(): o.editable=True return True else: self.isEditable=False return False (I added the isEditable attribute to cache if the object is editable, since I wasn't sure if get_profile() is lazy loaded or sends a request to the db with each iteration) >> But the issue is likely to be that each call to foo_set.all() creates a >> brand new queryset fetched straight from the database. So doing >> something on the result of calling .all() in the view is irrelevant >> when you call .all again in the template. That's probably right. But from what I understood, all() is a lazy loader, so when Django loaded the objects once out of the db, it should not do that again when the same object is called in a template. Or did I understand that wrong? That's not quite right. Calling .all() on a queryset is indeed lazy, which means that it doesn't call the database until it's evaluated or iterated. Subsequent iterations *on the same queryset object* do not hit the database again. However, calling foo.bar_set multiple times does *not* get the same queryset each time. So, each one is a separate query, and changing attributes on the instances returned by one iteration does not have any effect on those returned by a second. I discuss this a little in a blog entry here: http://blog.roseman.org.uk/2010/01/11/django-patterns-part-2-efficient-reverse-lookups/ >> The best way to do this is probably to keep the queryset in a variable >> and send it explicitly to the template, then iterate through that Yes that sounds possible. Just wondering if there is a cleaner way to do it - the ideal way would of course every object having access to the user in some way, but that seems impossible. Does this necessarily need to be a model method? Why not a custom template tag or filter, that you can pass the request.user object to? -- DR. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
