The full story: http://dpaste.com/3776/ The settings.py that got me there: http://dpaste.com/3774/
http://dpaste.com/3778/ That code does work, but notice that the value does not increment. On Mar 1, 2:45 am, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
