On 6/11/07, Don Arbow <[EMAIL PROTECTED]> 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
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
On 6/10/07, John D'Agostino <[EMAIL PROTECTED]> 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
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
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
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
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
buriy wrote:
>>> However, that's a good reason to have sessions pluggable -- if
>>> persistence is important, then you need
> > 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
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
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
On 6/6/07,
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?
On 6/6/07, Faulkner <[EMAIL PROTECTED]> 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
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?
On 6/1/07, kernel1983 <[EMAIL PROTECTED]> 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
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
14 matches
Mail list logo
