So, here's an interesting race condition, which causes request bleeding to
happen.
If you use a decorator on a view method, where the decorator is a class, the
class isn't created per request, it seems to stay the same throughout. So,
if you define any logic within this class, which depends on 'instance'
attributes or methods (i.e. self.*), then you will experience this problem.
The way we got around this, was to seperate our own logic into a different
class, and create a new instance of this class (per request) within the
__call__() method.
It's *very* difficult to spot this problem happening, and it's only because
our logic contained so many access control routines and safety checks, that
we received a debug email telling us something wasn't right.
*Works: *
class MembersAreaLogic:
def init():
return HttpResponse("Hit init()")
class MembersArea:
def __init__(self, orig_func):
self.orig_func = orig_func
def __call__(self, request, *args, **kwargs):
# Create new members area logic instance
ma = MembersAreaLogic(request)
# Perform the logic initialisation
_r = ma.init(*args, **kwargs)
# The logic init() will only ever return a response if it wishes to
# stop you from continuing to the actual view.
if _r:
return _r
# Execute the original view
return self.orig_func(request, ma, *args, **kwargs)
@MembersArea
def upgrade(request, ma, doorway, *args, **kwargs):
return HttpResponse("Hit View")
--
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.
