Proposal: Let session support backends

[kernel1983]

Now session can be only storaged in the database.

I think,django should be friendly with both new users and the mature
python users.

Since cache can support different kinds of backend, session should
also be.

Many people want to build application which can be deployed easily. If
they had to run "manage.py syncdb" before deploying, that'll be a bad
news!(for example: a web app for upload files)

I've write a session middleware myself instead of contrib.sessions. It
uses memory instead of database. But it can be used only in dev mode
just like the cache's simple backend.

So I think supporting vary backends is possible for the session.
Database may be the default backend but it is also flexible.

Django is going to be a big lib. Any one can choose some in it or
igone some.

[Jeremy Dunck]

On 6/1/07, kernel1983 <kerne...@gmail.com> wrote:
>
> Now session can be only storaged in the database.
>
> I think,django should be friendly with both new users and the mature
> python users.

Yeah, I agree, though I haven't gotten around to supplying a patch for
other backends. I do like the permanence and simplicity of the
db-backed store, but something like pear w/ occassional checkpointing
to a DB or appended file would be cool.

DB session has been good enough for me so far. I wonder what curse does? :)

[Faulkner]

Am having similar thoughts but instead of memory I want to use a
distributed cache. I'm starting to tinker with making my own session
middleware, but if someone was making a pluggable framework for
sessions I'd far prefer to use that.

Anyone seriously considering making a framework for this?

Ken

On Jun 2, 1:38 pm, "Jeremy Dunck" <jdu...@gmail.com> wrote:
> On 6/1/07, kernel1983 <kernel1...@gmail.com> wrote:
>
>
>
> > Nowsessioncan be only storaged in the database.

>
> > I think,django should be friendly with both new users and the mature
> > python users.
>
> Yeah, I agree, though I haven't gotten around to supplying a patch for
> other backends. I do like the permanence and simplicity of the
> db-backed store, but something like pear w/ occassional checkpointing
> to a DB or appended file would be cool.
>

> DBsessionhas been good enough for me so far. I wonder what curse does? :)

[Jacob Kaplan-Moss]

On 6/6/07, Faulkner <ken.fa...@gmail.com> wrote:
> Anyone seriously considering making a framework for this?

I, for one, would be all for a (drop-in, API-compatible) session layer
replacement with pluggable backends. Memcached sessions are a Good
Idea.

Jacob

[Ned Batchelder]

It sounds great, but memcached is a cache rather than a persistent store, so it doesn't guarantee to be able to give you back the data.  Is it OK for a session to drop because memcached flushed it out?  Or are you assuming you can size your memcached servers so that they never drop a session?

--Ned.

Jacob Kaplan-Moss wrote:

I, for one, would be all for a (drop-in, API-compatible) session layer
replacement with pluggable backends. Memcached sessions are a Good
Idea.

Jacob





.

  

-- 
Ned Batchelder, http://nedbatchelder.com

[Jacob Kaplan-Moss]

On 6/6/07, Ned Batchelder <n...@nedbatchelder.com> wrote:
> It sounds great, but memcached is a cache rather than a persistent store,
> so it doesn't guarantee to be able to give you back the data. Is it OK for
> a session to drop because memcached flushed it out? Or are you assuming you
> can size your memcached servers so that they never drop a session?

I've always assumed that session data is basically "disposable". Every
app I've written using sessions won't cause serious problems if the
sessions get flushed -- the worst that would happen in that users
would need to log in again.

[I certainly can't take credit for the concept; I first heard it in
one of Brad Fitzpatrick's (LiveJournal) talks, and I'm sure the ideas
been around for a while.]

However, that's a good reason to have sessions pluggable -- if
persistence is important, then you need db sessions.

Jacob

[Michael Trier]

I'm with Jacob; I've always considered an in memory solution one that
I was willing to live with. For smaller sites I like to use the
in-memory version of sqlite. It's easy to implement and works quite
well. Definitely having the session pluggable will be a huge help.

Michael

[Faulkner]

Although I personally use memcached for other purposes I wouldn't use
it for session data. Unlike others in the list I need to make sure
session data is persistent and wont get nuked if something crashes.
(well, within reason).

Either way, if we were able to get a pluggable backend up and running
then people can just do what they like.

I was thinking about just reimplementing SessionWrapper to do what I
want, but if there is a chance things will change, well I might hold
off ( or contribute)

Ken

On Jun 7, 9:42 am, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
wrote:

[buriy]

> > However, that's a good reason to have sessions pluggable -- if
> > persistence is important, then you need db sessions.

What about file for sessions like in php? I want sessions to be very
fast, but
memory solution is bad for development and production because you lose
all your session data between restarts.
sqlite is too heavy for them, but multithread and multiprocess access
should be supported anyway. bsddb backend maybe? +1 for this one. I
can write such one.

[Mike H]

I'd like to see alternative session backends so that I can write one
that uses memcached (which I use as standard on any high traffic PHP
sites I write).

Cheers,

Mike

[kernel1983]

I've write some code for a simple implement of the session middleware.
But there are some problem that I was too busy to solve these days.

It refers to the cache module's simple impl. Now it can be only used
in debug mode. And the session id is fixed(of course it's for testing)

I'm so glad that there are so many people have the same idea as me.

But how can we impl the idea? Any one can give us some advice?

[John D'Agostino]

I started implementing this a few months ago.

I've factored out SessionWrapper as SessionObject, as a base class and
(re)implemented the database session store on top. I've also got a
working implementation of a FileSession class.

Summary of changes:

Added a SESSION_ENGINE to settings.py
Added the methods get_new_session_key, save and _load to SessionObject
modified middleware.py to load the session store based on
SESSION_ENGINE (if SESSION_ENGINE does not exist, defaults to
database)
added DatabaseSession into django.contrib.session.database
added FileSession into django.contrib.session.file

The code needs cleaning up and I'm yet to test it with anything other
than the development server.
I will be able to clean the code up and submit a patch next week (if
it is wanted).

Would one of the core devs comment if this on the right track?

[Jacob Kaplan-Moss]

On 6/10/07, John D'Agostino <john.da...@gmail.com> wrote:
> Would one of the core devs comment if this on the right track?

Sounds about right to me; I'd love to see the code!

Jacob

[Don Arbow]

On Jun 1, 2007, at 8:34 PM, kernel1983 wrote:
> I've write a session middleware myself instead of contrib.sessions. It
> uses memory instead of database. But it can be used only in dev mode
> just like the cache's simple backend.

Did you search Trac? This looks like it's already been proposed and a
patch submitted:

http://code.djangoproject.com/ticket/2066

Don

[Jacob Kaplan-Moss]

On 6/11/07, Don Arbow <don...@nwlink.com> wrote:
> Did you search Trac? This looks like it's already been proposed and a
> patch submitted:
>
> http://code.djangoproject.com/ticket/2066

Yeah, I tried that code and found it pretty poorly written and full of
bugs. Looks like I didn't note that on the ticket (bad Jacob!).

Jacob