came across this today and it got me thinking:
What exactly is the rationale behind setting
django.contrib.sessions.backends.cache, as opposed to
django.contrib.sessions.backends.cached_db, and being pretty explicit about telling deployers to not override this? (At least that’s how I read the big
### ALWAYS THE SAME ### warning, although people have evidently overridden this setting in the past.)
I understand that it wouldn’t scale very well to use just a database-backed session store without caching, but since Django does have one that does use write-through caching, I’m curious why that’s evidently being warned against.
I think (correct me if I’m wrong) that most Open edX users will be deploying with memcached-backed caches, and one generally expects to be able to restart those with impunity. Using the
cached_db session backend would preserve user sessions across cache restarts (and across cache data eviction), so I wonder whence the choice for defaulting to a session backend that does not?
I’m pretty sure I’m missing some obvious concern with
django.contrib.sessions.backends.cached_db here, or maybe my assumptions about what caches people commonly use are wrong. Or maybe it is common to override
SESSION_ENGINE after all?
If anyone would like to shed some light on this I’d be grateful. Thank you!