Opened 18 years ago
Closed 17 years ago
#2066 closed enhancement (fixed)
[patch] Make session framework backends pluggable
Reported by: | 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)
Change History (15)
by , 18 years ago
Attachment: | session.zip added |
---|
comment:1 by , 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 , 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 , 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 , 18 years ago
Summary: | pluggable session handler → [patch] Make session framework backends pluggable |
---|
comment:5 by , 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 , 18 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:7 by , 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 , 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 , 17 years ago
I think with Session.objects.cache() method implemented, this patch becomes less attractive
comment:10 by , 17 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:11 by , 17 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:12 by , 17 years ago
Status: | new → assigned |
---|
comment:13 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
session handler with database and memcached, prototype.