[patch] Make session framework backends pluggable

session handler with database and memcached, prototype.

Sessions in Django are already pluggable. You simply specify a different middleware and a different app in 'INSTALLED_APPS', unless I'm missing something.

Are you suggesting that your code goes into 'contrib'? (if so you will need to clean up the code e.g. remove hard coded memcached server and similar).

What are the specific enhancements that your code brings over what Django already has?

From what I can tell, it seems this patch allows storage of session data in memcached instead of the database.

Yes, adrian. Sorry for my poor explaining and dirty code...

I picked 'django.contrib.sessions.*' module, and tried to make it possible to use memcached or database selectively.

If possible, I'd like to propose "SESSION_ENGINE" element in settings.py, so that we can select session storage from it - instead of hardcoded "_type = 'memcache'", as lukeplant pointed out.

But I didn't prefer to touch so much code - any other than the module originated from 'django.contrib.sessions.*', I decided to finish within it.

This is the reason why I hardcoded it.

any chance of getting this into contrib?

this will be one step do not requiring a database for django to work

FWW I just implemented the same thing (just to the cache) here  http://svn.zyons.python-hosting.com/trunk/zilbo/common/sessions/middleware.py

configurable session_engines

Discussion: http://groups.google.com/group/django-developers/browse_thread/thread/fd314ad62417db98/8e614855debfaee1

I'm actually +0 on this, after reading lukeplants comment.

Notes on the patch:

adds SESSION_ENGINE setting, and database, cache, file based session backends.

cache backend based on django.core.cache - although i do have code for a pure memcache session store.

to implement your own session engine, subclass SessionBase? and provide load,save,exists and delete methods

updated tests

updated docs (although they need improvement)

models.py hasn't been modified to maintain backwards capability; although all functionality is now in SessionBase?

Comments always welcome. Willing to improve the patch or answer any WTFs in the code.

A backend session framework shouldn't lose data when a memcache node goes down. I think that memcache could be used to speed up the select operations from the session, but all inserts should go to both memcache and to the db session backend.

Instead of a different backend, I would propose an extension to the existing backend to store the session data in memcache in addition for improved performance in high-read low-write situations. Perhaps a person could add an option to disable the database store if session data integrity is of no consequence and the application can tolerate logging all users out on a node failure.

I think with Session.objects.cache() method implemented, this patch becomes less attractive

(In [6333]) Fixed #2066: session data can now be stored in the cache or on the filesystem. This should be fully backwards-compatible (the database cache store is still the default). A big thanks to John D'Agostino for the bulk of this code.