Ok, I just confirmed my "problem" was caused by Django lazy loading the 
User object.

To confirm it, I just added something like this to my view:

test_var = "some text" + request.user

And I got an error message telling me I couldn't concatenate an str to a 
SimpleLazyObject. At this point the lazy loading logic hasn't got a real 
User object yet.

To bypass the lazy loading, hence return a non-cache view for authenticated 
users, I just needed to access some method or attribute to triggers an 
actual query on the User object. I ended up with this, which I think it's 
the simplest way:

bypass_lazyload = request.user.is_authenticated()

My conditional_cache decorator is no longer needed, although it was an 
interesting exercise.

I may not need to do this when I finish working with my views as I'll 
access some user methods and attributes on my templates anyway but it's 
good to know what was going on.

Regards.

On Thursday, August 23, 2012 2:40:47 AM UTC-3, ke1g wrote:
>
> I guess this is probably because the request.user object is created on 
> demand 
> (is a python "property").  The intent, I presume, is to not bother 
> fetching the session, 
> etc., unless it is used, as an optimization. 
>
> You should find that simply referring to request.user in the view 
> helps.  If so, then 
> you may want to add such to the views you want to leave uncached.  An 
> alternative 
> is to add a middleware that does this, which will incur the lookup 
> costs for all views. 
>
> Bill 
>
> On Tue, Aug 21, 2012 at 1:27 PM, Alexis Bellido 
> <ale...@ventanazul.com<javascript:>> 
> wrote: 
> > Hello, 
> > 
> > I am working on a Django 1.4 project and writing one simple application 
> > using per-site cache as described here: 
> > 
> > https://docs.djangoproject.com/en/dev/topics/cache/#the-per-site-cache 
> > 
> > I have correctly setup a local Memcached server and confirmed the pages 
> are 
> > being cached. 
> > 
> > Then I set CACHE_MIDDLEWARE_ANONYMOUS_ONLY = True because I don't want 
> to 
> > cache pages for authenticated users. 
> > 
> > I'm testing with a simple view that returns a template with 
> > render_to_response and RequestContext to be able to access user 
> information 
> > from the template and the caching works well so far, meaning it caches 
> pages 
> > just for anonymous users. 
> > 
> > And here's my problem. I created another view using a different template 
> > that doesn't access user information and noticed that the page was being 
> > cached even if the user was authenticated. After testing many things I 
> found 
> > that authenticated users were getting a cached page if the template 
> didn't 
> > print something from the user context variable. It's very simple to 
> test: 
> > print the user on the template and the page won't be cached for an 
> > authenticated user, remove the user on the template, refresh the page 
> while 
> > authenticated and check the HTTP headers and you will notice you're 
> getting 
> > a cached page. You should clear the cache between changes to see the 
> problem 
> > more clearly. 
> > 
> > I tested a little more and found that I could get rid of the user in the 
> > template and print request.user right on the view (which prints to the 
> > development server console) and that also fixed the problem of showing a 
> > cached page to an authenticated user but that's an ugly hack. 
> > 
> > A similar problem was reported here but never got an answer: 
> > 
> > https://groups.google.com/d/topic/django-users/FyWmz9csy5g/discussion 
> > 
> > I can probably write a conditional decorator to check if 
> > user.is_authenticated() and based on that use @never_cache on my view 
> but it 
> > seems like that defeats the purpose of using per-site cache, doesn't it? 
> > 
> > Any suggestions will be appreciated. 
> > 
> > Thanks! 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Django users" group. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msg/django-users/-/dZx3IJsXp9EJ. 
> > To post to this group, send email to 
> > django...@googlegroups.com<javascript:>. 
>
> > To unsubscribe from this group, send email to 
> > django-users...@googlegroups.com <javascript:>. 
> > For more options, visit this group at 
> > http://groups.google.com/group/django-users?hl=en. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/uzyHfkEIe7UJ.
To post to this group, send email to django-users@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.

Reply via email to