Karen, > ...It sounds like the problem is you have set up the results from > this view to be cached, yet this response cannot be cached as it > contains a file...
Got it; thanks so much. You were exactly right. Not only had I forgotten that I'd set up project-wide caching for this testbed project looong ago, I also hadn't updated it properly for django 1.x. > ...I'm not sure what you mean by saying it is not a Django > exception... I had enclosed my non-working code in a try-except block and the except wasn't picking up the error. From previous experience with mis- configuring mod_wsgi -- :) -- I knew that some errors only appear in the apache error log, which is where I found that traceback. I hadn't meant that django wasn't involved; was just trying to give more info. > ...you need to pay attention to what it is saying and start > investigating in the areas it is identifying... Since for a long time now my caching has been more explicit, not project-wide, I just didn't see what the traceback was really telling me. I'm much too embarrassed to let you know how much time I spent googling mod-wsgi & pickling, and python file pickling, so I won't. (I sometimes think that if developers would spend more time asking questions than banging their heads, we'd be up to web-8.0 by now.) A sincere thanks again. -Birkin On Nov 1, 2009, at 7:58 AM, Karen Tracey wrote: > On Sun, Nov 1, 2009 at 8:44 AM, birkin <birkin.di...@gmail.com> wrote: > > I forgot to note that the referenced mod_wsgi error is from the apache > error log; it is *not* a django exception. But because of the nearly > identical working code, I am suspecting my issue is with my django > code. > > I'm not sure what you mean by saying it is not a Django exception. > If you read the traceback: > > Traceback (most recent call last): > File "/Developer_3rd/django_src/django/core/handlers/wsgi.py", line > 243, in __call__ > response = middleware_method(request, response) > File "/Developer_3rd/django_src/django/middleware/cache.py", line > 93, in process_response > cache.set(cache_key, response, timeout) > File "/Developer_3rd/django_src/django/core/cache/backends/ > locmem.py", line 80, in set > self._set(key, pickle.dumps(value), timeout) > File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/ > python2.6/copy_reg.py", line 70, in _reduce_ex > raise TypeError, "can't pickle %s objects" % base.__name__ > TypeError: can't pickle file objects > > you see Django code identified. (Which doesn't necessarily mean > it's a problem in Django itself, it could equally well be your code > or configuration that is the real issue.) > > You also see cache is mentioned in the traceback, and the end error > message is that file object cannot be pickled. It sounds like the > problem is you have set up the results from this view to be cached, > yet this response cannot be cached as it contains a file. > > (If your working view is also cached, then perhaps there is some > difference in the headers being set that cause the cache to not > attempt to cache the attached file. I don't have time to look too > closely at either the code you've posted or how the cache behaves > for attached files right now. But the traceback is pointing out > exactly what the problem is, you need to pay attention to what it is > saying and start investigating in the areas it is identifying.) > > Karen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
