Hi, It sounds like you're looking at tests for django.contrib.sessions.backends.cached_db. If that is the case, then it's not unusual that you would end up calling the LocMem cache backend. The cached_db session backend does all of its reads from the cache, only falling back to the database sessions if the key is not found in the cache. So, unless you define a different cache backend in your settings.py file, the cached_db session backend will use the LocMem cache backend.
That doesn't necessarily mean you haven't run into a problem, of course. But it may explain some of what you're experiencing. Best, Stephen Burrows On Oct 4, 9:22 pm, Justin Holmes <jus...@justinholmes.com> wrote: > I posted this message on -users today, but at PaulM's urging, I'm > bringing it over here out of concern that it may reflect a bug in the > contrib.sessions test suite. > > Here's the original message from -users (some -dev only notes follow) : > > I am having a problem with contrib.sessions.tests.test_valid_key (line > 159). It's a mixin which in the failure case is mixed with > CacheDBSessionTests. > > The test raises: > > "AttributeError: 'bool' object has no attribute 'get'" > > The error is actually raised by session.save() on 164. > > Stepping inward reveals that sessions.backends.cached_db (line 18) > sets data thusly: > > data = cache.get(self.session_key, None) > > QUESTION #1 (maybe more suited for django-dev?): If I step in, I find > that debugging core.cache.backends.locmem.LocMemCache.get(), which is > odd since the TestCase is CacheDBSessionTests. Why is it testing > LocMemCache and not core.cache.backends.db.DatabaseCache? > > In this case, self.session_key is 1, and indeed the cache has a > pickled "True" for the key 1. In fact, during the course of debugging > core.cache.backends.locmem.LocMemCache.get(), we have found that in > every case during which the testrunner hits this method, 1 is a key > for pickled True. > > QUESTION #2: Why is the key 1 set to a pickled True? > > In this case, that True ends up being returned in > contrib.sessions.backends.base.SessionBase.get() (line 64). > > Thus, of course an error is raised. We are unable to understand why > the key 1 is set to pickled True in the locmem backend. > > NOW THE STRANGE PART: > > Iff we step in with a debugger and wait for > 3 seconds or so, the > method no longer returns True and instead returns an empty dict. In > this case, the test passes! > > We are baffled. Is this possibly an underlying race condition or > hotel room scenario (http://stackoverflow.com/questions/6441218)? > > [END DJANGO-USERS MESSAGE] > > I also want to point a few additional things here on the dev list: > > *We have tried this on two different computers with OSX and Linux and > we encounter the timing issue either way, every time. > *We put a breakpoint on django.core.cache.backends.db.get() (line 38) > which was never hit during the course of the sessions tests. > *We were hoping to find that the test runner hit one backend if we > didn't wait in state and another if we did. However, as noted in the > point above, that doesn't appear to be the case (unless we're missing > something about the way the backends are implemented, which is > possible) > *Thinking that using cached_db for the backend might result in .get() > being used only in LocMem, we also put a breakpoint in > backends.db.set(), thinking that both were going to be set. This > breakpoint was also never hit during the course of the sessions tests. > *The commit comment, by Russell Keith-Magee, seems like it is likely > related: "Fixed #15026 -- Added cleanup to the invalid key session > tests; when using Memcached as a cache backend, the cache-backed > session backends would fail on the second run due to leftover cache > artefacts. Thanks to jsdalton for the report and patch." > *#15026 seems to describe a substantially different problem, but it is > possible that the root cause is similar or the same: that unflushed > material in the cache persists between tests. > > We encountered this issue at DiscSpace, which is cool enough to let > freelancers work on issues in the django internals on company time if > we encounter them. > > -- > Justin Holmes > > Head Instructor, SlashRoot Collective > SlashRoot: Coffee House and Tech Dojo > 60 Main Street > New Paltz, NY 12561 > 845.633.8330 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
