On Sat, 2009-02-28 at 23:21 -0800, James Mowery wrote:
> from django.shortcuts import render_to_response
>
> class FullPageAdMiddleware(object):
> def process_view(self, request, view_func, view_args,
> view_kwargs):
>
> request.session['testing'] = request.session['testing'] + 1
>
> if request.session['testing'] > 10:
> return None
> else:
> return render_to_response('base/advertisement.html')
>
> This code fails to work properly. There are numerous issues with even
> this example, and I could probably simply the code further, but here
> are some of the errors:
>
> — Many times when return None occurs, my site's CSS and JavaScript
> files will not return, because supposedly the MIME type is not
> correct.
Very unlikely to be related to this piece of code, at least in
isolation. That would suggest that all middleware is broken, which is
unlikely.
What isn't clear from this code fragment is whether
request.session["testing"] is always going to exist (you can't add to it
if it's not there). Raising unexpected exceptions in middleware can lead
to unexpected problems.
> — "request.session['testing'] = request.session['testing'] + 1" does
> not increment by 1. It sometimes increments by 10, sometimes 20,
> sometimes 1.
Not really. Adding one to something always increments it by one.
Otherwise Python would be broken and that isn't the case. The question
is why isn't request.session["testing" having the value you expect --
whether that is initially or at save time.
I would start by putting in some debugging logging, logging the value of
request.session["testing"], both before and after the assignment. That
should at least establish that +1 works as expected.
> I've tried several other methods to increment: "request.session
> ['testing'] += 1" and many more, but all have failed.
Which suggests that +1 is working as you would expect.
> — That's only the beginning, but I figure these first two issues
> should be interesting enough for someone to examine.
Since these other problems are possibly symptomatic of the same thing,
how about not feeding the information out piecemeal? What else are you
seeing that's a problem here?
The right person to look at these problems is you, since you can
(apparently) reliably repeat it. The standard debugging practices apply.
Start by working out what is going on at the most local level possible.
That means things like the logging I show above.
Realise that there's a difference between when you change a session's
value and when it is saved to disk or other permanent storage.
>
> Note: I have tried this code on my production and test servers. I have
> the latest version of Django, and I've tried this on Python 2.6 and
> Python 2.4.
>
> I've also tried using different session storage options: db and cache,
> both with the same result.
Which suggests it isn't related to the session backend. That's useful to
have established. If you create a project that only has that view
middleware being used and otherwise has a view that returns pretty much
nothing (say, a static page), does the problem still appear?
How much do you have to remove from your existing project before the
problem goes away? Again, this comes back to trying to find the
absolutely simplest possible execution path that reliably demonstrates
the problem so that it's easier for you to debug.
All my experience says that the code fragment you've shown here isn't
the whole story. To confirm that, reduce your code to the point where it
is the whole story -- no other middleware, nothing more complicated than
returning a simple string from a view, etc. Then, when the problem
disappears, you know to start looking at the other things which may have
side-effects.
Hopefully that gives you some ideas on how to proceed. You're going to
be a little bit on your own because you can repeat the problem and it's
going to be very specific to the full details of your code.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
