Re: CACHE_MIDDLEWARE_ANONYMOUS_ONLY does not work if user is not printed by view or template

While
u = request.user
may not be enough,
request.user.username
should be (I don't think you even have to put it in a variable, python
will evaluate it even if the result is discarded).

On Thu, Aug 23, 2012 at 9:20 AM, Alexis Bellido <alexis@ventanazul.com> wrote:
> 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>
>> 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.
>> > To unsubscribe from this group, send email to
>> > django-users...@googlegroups.com.
>> > 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+unsubscribe@googlegroups.com.
> 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 post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.