Opened 18 years ago

Closed 17 years ago

#2066 closed enhancement (fixed)

[patch] Make session framework backends pluggable

Reported by: hironobu@… Owned by: Jacob
Component: Contrib apps Version: dev
Severity: normal Keywords: session handling
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I want a new session handler, suitable with django.contrib.auth, admin, etc... getting along with existing any modules of Django. I want session storage apart from contents database, and enhancing for load balancing and high availability. I think it is good merit for Django to have an expandable session handling system.

If there are any needs for such system, I'd like to post a patch to fulfill this feature.
(...Or maybe developer team is now implementing same function, though. ...Then sorry. (_ _) )

Attachments (2)

session.zip (3.7 KB ) - added by hironobu@… 18 years ago.
session handler with database and memcached, prototype.
session_engines.diff (25.6 KB ) - added by John D'Agostino <john.dagostino@…> 17 years ago.
configurable session_engines

Download all attachments as: .zip

Change History (15)

by hironobu@…, 18 years ago

Attachment: session.zip added

session handler with database and memcached, prototype.

comment:1 by Luke Plant, 18 years ago

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?

comment:2 by Adrian Holovaty, 18 years ago

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

comment:3 by hironobu@…, 18 years ago

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.

comment:4 by Adrian Holovaty, 18 years ago

Summary: pluggable session handler[patch] Make session framework backends pluggable

comment:5 by anonymous, 18 years ago

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

comment:6 by Simon G. <dev@…>, 17 years ago

Triage Stage: UnreviewedDesign decision needed

by John D'Agostino <john.dagostino@…>, 17 years ago

Attachment: session_engines.diff added

configurable session_engines

comment:7 by John D'Agostino <john.dagostino@…>, 17 years ago

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.

comment:8 by anonymous, 17 years ago

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.

comment:9 by anonymous, 17 years ago

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

comment:10 by Yuri Baburov, 17 years ago

Owner: changed from nobody to Yuri Baburov
Status: newassigned

comment:11 by Jacob, 17 years ago

Owner: changed from Yuri Baburov to Jacob
Status: assignednew

comment:12 by Jacob, 17 years ago

Status: newassigned

comment:13 by Jacob, 17 years ago

Resolution: fixed
Status: assignedclosed

(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.

Note: See TracTickets for help on using tickets.
Back to Top