You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-commits@quetz.apache.org by nl...@apache.org on 2005/09/20 23:28:36 UTC
svn commit: r290569 -
/httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Author: nlehuen
Date: Tue Sep 20 14:28:32 2005
New Revision: 290569
URL: http://svn.apache.org/viewcvs?rev=290569&view=rev
Log:
A first try at implementing a session storage relying on SQLite. It is slower than FileSession but could scale better ?
Added:
httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Added: httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
URL: http://svn.apache.org/viewcvs/httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py?rev=290569&view=auto
==============================================================================
--- httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py (added)
+++ httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py Tue Sep 20 14:28:32 2005
@@ -0,0 +1,150 @@
+ #
+ # Copyright 2004 Apache Software Foundation
+ #
+ # Licensed under the Apache License, Version 2.0 (the "License"); you
+ # may not use this file except in compliance with the License. You
+ # may obtain a copy of the License at
+ #
+ # http://www.apache.org/licenses/LICENSE-2.0
+ #
+ # Unless required by applicable law or agreed to in writing, software
+ # distributed under the License is distributed on an "AS IS" BASIS,
+ # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ # implied. See the License for the specific language governing
+ # permissions and limitations under the License.
+ #
+ # Originally developed by Gregory Trubetskoy.
+ #
+ # $Id: Session.py 231126 2005-08-09 22:26:38Z jgallacher $
+from Session import *
+from time import time
+
+try:
+ # If this code is included into Session.py,
+ # we don't want to add a dependency to SQLite
+ from pysqlite2 import dbapi2 as sqlite
+except:
+ pass
+else:
+ class SQLiteSession(BaseSession):
+ """ A session implementation using SQLite to store session data.
+ pysqlite2 is required, see http://pysqlite.org/
+ """
+
+ def __init__(self, req, filename=None, sid=0, secret=None, timeout=0, lock=1):
+ # if no filename is given, get it from PythonOption
+ if not filename:
+ opts = req.get_options()
+ if opts.has_key("session_filename"):
+ filename = opts["session_filename"]
+ else:
+ # or build a session file in a temporary directory
+ filename = os.path.join(
+ opts.get('session_directory', tempdir),
+ 'mp_sess.sqlite'
+ )
+
+ self.filename = filename
+
+ # check whether the sessions table exists, and create it if not
+ db = sqlite.connect(self.filename)
+ try:
+ try:
+ cur = db.cursor()
+ cur.execute("""
+ select name from sqlite_master
+ where name='sessions' and type='table'
+ """)
+ if cur.fetchone() is None:
+ cur.execute("""
+ create table sessions
+ (id text,data blob,timeout real)
+ """)
+ cur.execute("""
+ create unique index idx_session on sessions (id)
+ """)
+ db.commit()
+ finally:
+ cur.close()
+ finally:
+ db.close()
+
+ BaseSession.__init__(self, req, sid=sid, secret=secret,
+ timeout=timeout, lock=lock)
+
+ def count(self):
+ db = sqlite.connect(self.filename)
+ try:
+ try:
+ cur = db.cursor()
+ cur.execute("select count(*) from sessions")
+ return cur.fetchone()[0]
+ finally:
+ cur.close()
+ finally:
+ db.close()
+
+ def do_cleanup(self):
+ db = sqlite.connect(self.filename)
+ try:
+ try:
+ cur = db.cursor()
+ cur.execute(
+ "delete from sessions where timeout<?",
+ (time(),)
+ )
+ db.commit()
+ finally:
+ cur.close()
+ finally:
+ db.close()
+
+ def do_load(self):
+ db = sqlite.connect(self.filename)
+ try:
+ try:
+ cur = db.cursor()
+ cur.execute(
+ "select data from sessions where id=?",
+ (self._sid,)
+ )
+ row = cur.fetchone()
+ if row is None:
+ return None
+ else:
+ return cPickle.loads(str(row[0]))
+ finally:
+ cur.close()
+ finally:
+ db.close()
+
+ def do_save(self, dict):
+ db = sqlite.connect(self.filename)
+ try:
+ try:
+ cur = db.cursor()
+ data = buffer(cPickle.dumps(dict,2))
+ timeout = self._accessed+self._timeout
+ cur.execute("""
+ insert or replace into sessions (id,data,timeout)
+ values (?,?,?)
+ """,(self._sid,data,timeout))
+ db.commit()
+ finally:
+ cur.close()
+ finally:
+ db.close()
+
+ def do_delete(self):
+ db = sqlite.connect(self.filename)
+ try:
+ try:
+ cur = db.cursor()
+ cur.execute(
+ "delete from sessions where id=?",
+ (self._sid,)
+ )
+ finally:
+ cur.close()
+ finally:
+ db.close()
Re: svn commit: r290569 - /httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
it's python-cvs@httpd.apache.org
On Thu, 22 Sep 2005, Jim Gallacher wrote:
> Grisha,
>
> Your message implies that there is a mailing list for mod_python svn commit
> messages. How can I subscribe to this?
>
> Thanks,
> Jim
>
> Gregory (Grisha) Trubetskoy wrote:
>>
>> Can we have a little discussion on pros/cons of this? Does this make
>> mod_python dependent on sqlite?
>>
>> Thanks,
>>
>> Grisha
>>
>>
>> On Tue, 20 Sep 2005 nlehuen@apache.org wrote:
>>
>>> Author: nlehuen
>>> Date: Tue Sep 20 14:28:32 2005
>>> New Revision: 290569
>>>
>>> URL: http://svn.apache.org/viewcvs?rev=290569&view=rev
>>> Log:
>>> A first try at implementing a session storage relying on SQLite. It is
>>> slower than FileSession but could scale better ?
>>>
>>> Added:
>>> httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
>>>
>>> Added: httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
>>> URL:
>>> http://svn.apache.org/viewcvs/httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py?rev=290569&view=auto
>>
>
Re: svn commit: r290569 - /httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Posted by Jim Gallacher <jg...@sympatico.ca>.
Grisha,
Your message implies that there is a mailing list for mod_python svn
commit messages. How can I subscribe to this?
Thanks,
Jim
Gregory (Grisha) Trubetskoy wrote:
>
> Can we have a little discussion on pros/cons of this? Does this make
> mod_python dependent on sqlite?
>
> Thanks,
>
> Grisha
>
>
> On Tue, 20 Sep 2005 nlehuen@apache.org wrote:
>
>> Author: nlehuen
>> Date: Tue Sep 20 14:28:32 2005
>> New Revision: 290569
>>
>> URL: http://svn.apache.org/viewcvs?rev=290569&view=rev
>> Log:
>> A first try at implementing a session storage relying on SQLite. It is
>> slower than FileSession but could scale better ?
>>
>> Added:
>> httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
>>
>> Added: httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
>> URL:
>> http://svn.apache.org/viewcvs/httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py?rev=290569&view=auto
>>
>
Name suggestions svn 3.2 stable branch
Posted by Jim Gallacher <jg...@sympatico.ca>.
Gregory (Grisha) Trubetskoy wrote:
>
> On Thu, 22 Sep 2005, Jim Gallacher wrote:
>> On another note, if we are starting to roll with new features for 3.3
>> I would suggest we need to immediately create a new svn branch for 3.2
>> bugfixes.
>
>
> Yes
Any preference for a branch name? Some suggestions:
branches/release-3.2
branches/release-3.2-stable
branches/release-3.2-bugfixes
Jim
Re: svn commit: r290569 - /httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Posted by Jim Gallacher <jg...@sympatico.ca>.
Gregory (Grisha) Trubetskoy wrote:
>
> On Thu, 22 Sep 2005, Jim Gallacher wrote:
>
>> Gregory (Grisha) Trubetskoy wrote:
>>
>>>
>>> OK, my next question would be - is MySQL, PostgreSQL, Informix,
>>> Oracle, etc next,
>>
>>
>> Yes. ;)
>
>
> And how did we arrive at this decision? :-)
Oh, there was no decision. It's just the nature of open source software
to eventually grow to include MySQL and PostgreSQL support. And if you
support those 2, well what do you have against Informix? Informix? bah!
Everyone knows the one true database is Firebird. And so it goes. I'm
pretty sure it's one of Newton's Laws, like the conservation of momemtum. :)
> I'd be pretty strongly -1 on this, as it's got little to do with
> Apache/Python integration which is our core mission.
>
> I think it might be interesting to see something like an ANSI SQL-92
> compatible session with some suggestions on how it can be easily
> integrated with your database vendor of choice, but deifinitely not
> support specific database vendors, except for those whose support exists
> natively in the Python distribution (which is none at this point).
I like this idea. It's a keeper.
>>> and is this the path we want to take, or is there something about
>>> sqlite that makes it unique?
>
>
> ...so nothing unique about sqlite? If so, I don't think it should be
> part of mod_python unless/until it is standard in Python, then we can
> discuss it.
>
>> I don't know if it is that path we *want* to take, but I think there
>> is a certain inevitability that it's the path we *will* take.
>
>
> We will take the path we want :-)
Yes, but feature bloat is just soooo tempting.
>> I'm personally thinking about a MySQL backend, not because I need it
>> but because I'm curious to compare the performance with FileSession.
>
>
> But does this mean it has to be included in mod_python?
>
>> The best approach might be to refactor Session.py to easily
>> accommodate subclasses for other persistent stores.
>
>
> That I can agree with. Not necessarily "Session.py" but rather the
> Session class (inside Session.py). I remember that a lot of time/thought
> went into it, so it's not like it's going to be a "no-brainer" though.
>
>> Any new session subclasses get their own file eg.
>>
>> mod_python/sessions/sqlite.py
>
>
> -1
>
>> mod_python/sessions/mysql.py
>
>
> -1
Are you objecting to the idea of having session subclasses in their own
modules under mod_python/sessions/ or just reiterating your objection to
our providing support for specific database backends?
>> The current Session.py could stay as is, or we could split
>> FileSession, DbmSession and MemorySession into their own files
>
>
> I think at this point it'd be cleaner to move the FileSession class into
> the Session.py file rather than split into individual files. I'm not
> sure. Something to ponder upon, I guess.
>
>> and just have a stub in Session.py for backward compatability.
>
>
> Not "backwards compatibility", but "default". Using Session should let
> you use the session mechanism that is most recommended if you do not
> want to think about it too much.
>
You may have misunderstood my point. I think we could reorganize the
session code to make it easier to support future session subclasses,
whether provided by ourselves or third parties. (And I'm not suggesting
that there is a problem with Session.BaseSession - it's pretty easy to
create subclasses from it). I just want to make it easy for a user to
integrate their own session subclass and have it seamlessly available
from Session.Session(). That's probably still not clear so at some point
I'll cobble together some pseudo code which will better illustrate what
I'm thinking.
Regards,
Jim
Re: svn commit: r290569 - /httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Posted by Nicolas Lehuen <ni...@gmail.com>.
2005/9/23, Jorey Bump <li...@joreybump.com>:
>
> Nicolas Lehuen wrote:
>
> > That being said, why SQLite ? Because it's simple to install and use (no
> > administration required). You just give it a file name and you're ready
> > to roll. Plus, I really wanted to experiment with SQLite :).
> >
> > I must confess that the current implementation seems 30% slower than
> > FileSession, but we are not cluttering the filesystem (due to FS
> > clusters, FileSession files all use a lot of disk space) and cleaning up
> > old sessions is very fast (I used a DELETE FROM sessions WHERE ... just
> > like Jim described), contrary to FileSession, so there is a tradeoff.
>
> Doesn't SQLite suffer from similar locking issues you'd encounter with a
> pickle? Wouldn't the lack of concurrent write access cause problems on a
> busy server?
>
Yes it does ! I'm trying to find the best transaction isolation level, but
at the end of the day, SQLite locks the full file on commits, which is why
it is ultimately less scalable than table-level or row-level locking DBMSes.
But, this is the same problem for DBMSession (for which we had to handle
locking by ourselves, remember !).
Regards,
Nicolas
Re: svn commit: r290569 - /httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Posted by Jorey Bump <li...@joreybump.com>.
Nicolas Lehuen wrote:
> That being said, why SQLite ? Because it's simple to install and use (no
> administration required). You just give it a file name and you're ready
> to roll. Plus, I really wanted to experiment with SQLite :).
>
> I must confess that the current implementation seems 30% slower than
> FileSession, but we are not cluttering the filesystem (due to FS
> clusters, FileSession files all use a lot of disk space) and cleaning up
> old sessions is very fast (I used a DELETE FROM sessions WHERE ... just
> like Jim described), contrary to FileSession, so there is a tradeoff.
Doesn't SQLite suffer from similar locking issues you'd encounter with a
pickle? Wouldn't the lack of concurrent write access cause problems on a
busy server?
Re: SQLite and other things [was Re: svn commit: r290569]
Posted by Robert Sanderson <az...@liverpool.ac.uk>.
>So based on the above, I think SQLite support should be removed.
Not that I've done much apart from follow things (and suggest the
revision of how the connection is read) but I agree with Grisha on this
part.
>The thing we need to address is what to do with nifty things we create
>but that don't qualify for inclusion. The idea of a 'contrib' directory
>has been floated around for a while, I for one am against it for the same
>reasons above - it should either be 100% supported or not included at all
>IMO.
On the other hand, *quality* contributed code IMO could be distributed
but not 'supported' (for what little distinction there is). At the very
least it gives people something to base their own code on, rather than
trying to develop in a vacuum or doing time consuming web searches.
-- Rob
Re: SQLite and other things [was Re: svn commit: r290569]
Posted by Jim Gallacher <jg...@sympatico.ca>.
Gregory (Grisha) Trubetskoy wrote:
>
> Just to put this SQLite business to rest.
>
> I think that (and we can discuss this - I don't set laws, I just have
> opinions that may not always beright, so feel free to comment)
> mod_python should do fewer things but do them exceptionally well.
>
> Roughly speaking, to be included in mod_python something has to fall
> into the category of Apache/Python integration or demonstrate to be
> addressing a challenge introduced by the mod_python environment and too
> difficult to address by an average (Python) programmer.
>
> Given this definition, the reason Sessions were included was that it
> turned out that implementing session support under mod_python was not a
> trivial task and required use of APR locking (which was implemented for
> Sessions IIRC).
>
> Similar reasoning behind the inclusion of PSP - it's not something an
> average Python programmer could whip up, but it is also a bit of a
> stretch and its inclusion was (and is) controversial.
>
> Cookies were included because the standard Python lib module assumed a
> CGI environment and was (and is) IMHO lacking in many ways.
>
> On a more practical note - interoperation with third-party applications
> creates a dependency. So even though SQLite would not have to be
> installed in order for mod_python to work, it _would_ have to be
> installed in order for the test suite to run. Or you don't test it, in
> which case you risk it becoming broken and not noticing it. And if we
> were to continue down this path, imagine having to have MySQL,
> PostgreSQL and Oracle installed in order to run the test suite - we'd
> never get any +1's on the list this way :-)
>
> So based on the above, I think SQLite support should be removed.
>
> The thing we need to address is what to do with nifty things we create
> but that don't qualify for inclusion. The idea of a 'contrib' directory
> has been floated around for a while, I for one am against it for the
> same reasons above - it should either be 100% supported or not included
> at all IMO.
>
> I think for the time being the best approach is for people to use their
> own resources to publish contrib-type code on the web and just follow
> the usual process of announcing it on the list.
>
> Grisha
Grisha,
I think much what you write could be distilled into "The mod_python
Philosophy" and should included in the documenation as such.
I'm ambivalent on the subject of a contrib directory. In theory it's a
great idea. In practice it often seems that a project's contributed code
is out of date and unmaintained. I think we should *only* ship
production quality code. This means that we would need to take
responsibilty for maintaining contributed code which I think would be a
bad idea - our resources are too limited.
It may be worthwhile expanding on our example code however. I don't
think people expect examples to be full fledged implementations, but can
be a great starting point for a user to create their own code. I guess
we can still get into dependency problems here as well though. There are
no easy answers.
Regards,
Jim
Re: testhandler.py [was SQLite and other things ]
Posted by Jim Gallacher <jg...@sympatico.ca>.
Nick wrote:
> Jim Gallacher wrote:
> > Nicolas Lehuen wrote:
> >> I thought that all this mptest.py thing was a bit disturbing, as
> >> usually people took the wrong impression that they had to call the
> >> /test/mptest.py URL, that is they thought that the handler system was
> >> a bit like the publisher system. So by providing a test handler in the
> >> box, we could make sure that the installation was correct without
> >> having to cope with all the fuss about where mptest.py should be
> >> located and what URL to use to make sure everything is working.
> >
> > I think this is a worthwhile addition as it should make it easier to get
> > new people started with mod_python.
>
> Looking at this file, it's a great way to verify that mod_python is
> working correctly, and it's pretty thorough in checking the apache
> internals. However, it's neither simple nor intuitive for new people to
> get started with mod_python I think. For a newbie, it looks like it
> could be overwhelming.
>
Allow me to rephrase. It is a worth while addition as it should make it
easier *for experienced users* to assist newbies having problems getting
started with mod_python. :)
Regards,
Jim
Re: SQLite and other things [was Re: svn commit: r290569]
Posted by Nick <ni...@dd.revealed.net>.
Jim Gallacher wrote:
> Nicolas Lehuen wrote:
>> I thought that all this mptest.py thing was a bit disturbing, as
>> usually people took the wrong impression that they had to call the
>> /test/mptest.py URL, that is they thought that the handler system was
>> a bit like the publisher system. So by providing a test handler in the
>> box, we could make sure that the installation was correct without
>> having to cope with all the fuss about where mptest.py should be
>> located and what URL to use to make sure everything is working.
>
> I think this is a worthwhile addition as it should make it easier to get
> new people started with mod_python.
Looking at this file, it's a great way to verify that mod_python is working
correctly, and it's pretty thorough in checking the apache internals.
However, it's neither simple nor intuitive for new people to get started
with mod_python I think. For a newbie, it looks like it could be overwhelming.
Nick
Re: SQLite and other things [was Re: svn commit: r290569]
Posted by Jim Gallacher <jg...@sympatico.ca>.
Nicolas Lehuen wrote:
> 2005/9/24, Gregory (Grisha) Trubetskoy <grisha@apache.org
> <ma...@apache.org>>:
>
>
>
> On Sat, 24 Sep 2005, Nicolas Lehuen wrote:
>
> > Maybe we should distribute the publisher as an extension module ?
> Alongside
> > with Vampire, Django, and other high-level frameworks ?
>
> I'd leave the publisher where it is. Mod_python needs at least one
> handler
> to demonstrate how it works and provide a quick and easy way to get
> started, and that handler better not be cgihandler. This is why I think
> the publisher should be primitive and any of its shortcomings are OK,
> becuase if you need something fancy - you can use Vampire, etc.
>
> I did not notice there was a testhandler.py there. In general we do way
> too much committing and too little discussion, I'd like to see this
> ratio
> reversed. Can we get a little thread on what the testhandler is
> (sorry if
> this was discussed and I wasn't paying attention).
>
> Grisha
>
>
> That's another of my commit :). The purpose of the testhandler was to
> provide an handler "in the box" so that people could test the Apache
> side of their configuration without having to write an handler.
>
> I thought that all this mptest.py thing was a bit disturbing, as usually
> people took the wrong impression that they had to call the
> /test/mptest.py URL, that is they thought that the handler system was a
> bit like the publisher system. So by providing a test handler in the
> box, we could make sure that the installation was correct without having
> to cope with all the fuss about where mptest.py should be located and
> what URL to use to make sure everything is working.
I think this is a worthwhile addition as it should make it easier to get
new people started with mod_python.
Jim
Re: SQLite and other things [was Re: svn commit: r290569]
Posted by Nicolas Lehuen <ni...@gmail.com>.
2005/9/24, Gregory (Grisha) Trubetskoy <gr...@apache.org>:
>
>
>
> On Sat, 24 Sep 2005, Nicolas Lehuen wrote:
>
> > Maybe we should distribute the publisher as an extension module ?
> Alongside
> > with Vampire, Django, and other high-level frameworks ?
>
> I'd leave the publisher where it is. Mod_python needs at least one handler
> to demonstrate how it works and provide a quick and easy way to get
> started, and that handler better not be cgihandler. This is why I think
> the publisher should be primitive and any of its shortcomings are OK,
> becuase if you need something fancy - you can use Vampire, etc.
>
> I did not notice there was a testhandler.py there. In general we do way
> too much committing and too little discussion, I'd like to see this ratio
> reversed. Can we get a little thread on what the testhandler is (sorry if
> this was discussed and I wasn't paying attention).
>
> Grisha
>
That's another of my commit :). The purpose of the testhandler was to
provide an handler "in the box" so that people could test the Apache side of
their configuration without having to write an handler.
I thought that all this mptest.py thing was a bit disturbing, as usually
people took the wrong impression that they had to call the /test/mptest.py
URL, that is they thought that the handler system was a bit like the
publisher system. So by providing a test handler in the box, we could make
sure that the installation was correct without having to cope with all the
fuss about where mptest.py should be located and what URL to use to make
sure everything is working.
Regards,
Nicolas
Re: SQLite and other things [was Re: svn commit: r290569]
Posted by Jorey Bump <li...@joreybump.com>.
Nick wrote:
> As a long time user of mod_python, I
> would add that I personally disagree with including Sessions, psp,
> publisher, etc. in the base distribution, since these things seem to
> have held up releases. I don't use any of those things as all with
> mod_python, and I don't see how they're necessary to use mod_python for
> what it's for: creating apache extension modules in Python.
I agree, and my usage is the exact opposite of Nick's. I use mod_python
exclusively with Publisher, and even I think it's odd to include it.
With a stable base distribution and a repository of supported handlers,
it may not be necessary to touch the core if you're simply trying to
address an issue in a handler.
> But there needs to be something. What do you see on the list all the
> time? People asking how do I implement database pooling, how to I use
> sessions, here's my database implementation for sessions. I say put the
> publisher there as well, since it doesn't have anything to do with the
> philosophy of mod_python, even by Grisha's definition, and solves some
> release issues with mod_python itself (can anyone say imports?).
It also gives handler writers an incentive to contribute code to the
core without having to study the impact on other handlers included in
the main distribution. If it raises issues, handler maintainers will
have an opportunity to voice their concerns or adapt.
Re: SQLite and other things [was Re: svn commit: r290569]
Posted by Jim Gallacher <jg...@sympatico.ca>.
Nicolas Lehuen wrote:
> OK, I agree to remove SQLiteSession. I'll put it on my own website for
> curious people to use it if they want.
>
> However, this means that the PythonOption session must be extended for
> third-party developers to be able to provide their own session
> implementation.
I want this feature added for 3.3 anyway.
Jim
> Regards,
> Nicolas
>
> 2005/9/23, Nick <nick@dd.revealed.net <ma...@dd.revealed.net>>:
>
> Gregory (Grisha) Trubetskoy wrote:
> > I think that (and we can discuss this - I don't set laws, I just have
> > opinions that may not always beright, so feel free to comment)
> > mod_python should do fewer things but do them exceptionally well.
>
> I would agree with that totally. As a long time user of mod_python,
> I would
> add that I personally disagree with including Sessions, psp,
> publisher, etc.
> in the base distribution, since these things seem to have held up
> releases.
> I don't use any of those things as all with mod_python, and I
> don't see
> how they're necessary to use mod_python for what it's for: creating
> apache
> extension modules in Python.
>
> > The thing we need to address is what to do with nifty things we
> create
> > but that don't qualify for inclusion. The idea of a 'contrib'
> directory
> > has been floated around for a while, I for one am against it for the
> > same reasons above - it should either be 100% supported or not
> included
> > at all IMO.
>
> If that's the case, there definitely needs to be a central place for
> contributed code like this. I think a contrib directory is
> convenient, but
> I also know the issues of who decides what to put in there, how much
> do put
> include, how do you gently waive off support requests for its contents.
>
> But there needs to be something. What do you see on the list all
> the time?
> People asking how do I implement database pooling, how to I use
> sessions,
> here's my database implementation for sessions. I say put the publisher
> there as well, since it doesn't have anything to do with the
> philosophy of
> mod_python, even by Grisha's definition, and solves some release
> issues with
> mod_python itself (can anyone say imports?).
>
> Nick
>
>
Re: SQLite and other things [was Re: svn commit: r290569]
Posted by Nicolas Lehuen <ni...@gmail.com>.
OK, I agree to remove SQLiteSession. I'll put it on my own website for
curious people to use it if they want.
However, this means that the PythonOption session must be extended for
third-party developers to be able to provide their own session
implementation.
Regards,
Nicolas
2005/9/23, Nick <ni...@dd.revealed.net>:
>
> Gregory (Grisha) Trubetskoy wrote:
> > I think that (and we can discuss this - I don't set laws, I just have
> > opinions that may not always beright, so feel free to comment)
> > mod_python should do fewer things but do them exceptionally well.
>
> I would agree with that totally. As a long time user of mod_python, I
> would
> add that I personally disagree with including Sessions, psp, publisher,
> etc.
> in the base distribution, since these things seem to have held up
> releases.
> I don't use any of those things as all with mod_python, and I don't see
> how they're necessary to use mod_python for what it's for: creating apache
> extension modules in Python.
>
> > The thing we need to address is what to do with nifty things we create
> > but that don't qualify for inclusion. The idea of a 'contrib' directory
> > has been floated around for a while, I for one am against it for the
> > same reasons above - it should either be 100% supported or not included
> > at all IMO.
>
> If that's the case, there definitely needs to be a central place for
> contributed code like this. I think a contrib directory is convenient, but
> I also know the issues of who decides what to put in there, how much do
> put
> include, how do you gently waive off support requests for its contents.
>
> But there needs to be something. What do you see on the list all the time?
> People asking how do I implement database pooling, how to I use sessions,
> here's my database implementation for sessions. I say put the publisher
> there as well, since it doesn't have anything to do with the philosophy of
> mod_python, even by Grisha's definition, and solves some release issues
> with
> mod_python itself (can anyone say imports?).
>
> Nick
>
Re: SQLite and other things [was Re: svn commit: r290569]
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Sat, 24 Sep 2005, Nicolas Lehuen wrote:
> Maybe we should distribute the publisher as an extension module ? Alongside
> with Vampire, Django, and other high-level frameworks ?
I'd leave the publisher where it is. Mod_python needs at least one handler
to demonstrate how it works and provide a quick and easy way to get
started, and that handler better not be cgihandler. This is why I think
the publisher should be primitive and any of its shortcomings are OK,
becuase if you need something fancy - you can use Vampire, etc.
I did not notice there was a testhandler.py there. In general we do way
too much committing and too little discussion, I'd like to see this ratio
reversed. Can we get a little thread on what the testhandler is (sorry if
this was discussed and I wasn't paying attention).
Grisha
Re: SQLite and other things [was Re: svn commit: r290569]
Posted by Nicolas Lehuen <ni...@gmail.com>.
2005/9/23, Nick <ni...@dd.revealed.net>:
>
> But there needs to be something. What do you see on the list all the time?
> People asking how do I implement database pooling, how to I use sessions,
> here's my database implementation for sessions. I say put the publisher
> there as well, since it doesn't have anything to do with the philosophy of
> mod_python, even by Grisha's definition, and solves some release issues
> with
> mod_python itself (can anyone say imports?).
>
> Nick
>
Note that a review of the import system is needed even if we excluded the
publisher from the core distribution. mod_python needs to dynamically import
its handlers and the current way it is done is somewhere between error prone
and bugged.
Maybe we should distribute the publisher as an extension module ? Alongside
with Vampire, Django, and other high-level frameworks ?
Regards,
Nicolas
Re: SQLite and other things [was Re: svn commit: r290569]
Posted by Nick <ni...@dd.revealed.net>.
Gregory (Grisha) Trubetskoy wrote:
> I think that (and we can discuss this - I don't set laws, I just have
> opinions that may not always beright, so feel free to comment)
> mod_python should do fewer things but do them exceptionally well.
I would agree with that totally. As a long time user of mod_python, I would
add that I personally disagree with including Sessions, psp, publisher, etc.
in the base distribution, since these things seem to have held up releases.
I don't use any of those things as all with mod_python, and I don't see
how they're necessary to use mod_python for what it's for: creating apache
extension modules in Python.
> The thing we need to address is what to do with nifty things we create
> but that don't qualify for inclusion. The idea of a 'contrib' directory
> has been floated around for a while, I for one am against it for the
> same reasons above - it should either be 100% supported or not included
> at all IMO.
If that's the case, there definitely needs to be a central place for
contributed code like this. I think a contrib directory is convenient, but
I also know the issues of who decides what to put in there, how much do put
include, how do you gently waive off support requests for its contents.
But there needs to be something. What do you see on the list all the time?
People asking how do I implement database pooling, how to I use sessions,
here's my database implementation for sessions. I say put the publisher
there as well, since it doesn't have anything to do with the philosophy of
mod_python, even by Grisha's definition, and solves some release issues with
mod_python itself (can anyone say imports?).
Nick
SQLite and other things [was Re: svn commit: r290569]
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Just to put this SQLite business to rest.
I think that (and we can discuss this - I don't set laws, I just have
opinions that may not always beright, so feel free to comment) mod_python
should do fewer things but do them exceptionally well.
Roughly speaking, to be included in mod_python something has to fall into
the category of Apache/Python integration or demonstrate to be addressing
a challenge introduced by the mod_python environment and too difficult to
address by an average (Python) programmer.
Given this definition, the reason Sessions were included was that it
turned out that implementing session support under mod_python was not a
trivial task and required use of APR locking (which was implemented for
Sessions IIRC).
Similar reasoning behind the inclusion of PSP - it's not something an
average Python programmer could whip up, but it is also a bit of a stretch
and its inclusion was (and is) controversial.
Cookies were included because the standard Python lib module assumed a CGI
environment and was (and is) IMHO lacking in many ways.
On a more practical note - interoperation with third-party applications
creates a dependency. So even though SQLite would not have to be installed
in order for mod_python to work, it _would_ have to be installed in order
for the test suite to run. Or you don't test it, in which case you risk it
becoming broken and not noticing it. And if we were to continue down this
path, imagine having to have MySQL, PostgreSQL and Oracle installed in
order to run the test suite - we'd never get any +1's on the list this
way :-)
So based on the above, I think SQLite support should be removed.
The thing we need to address is what to do with nifty things we create
but that don't qualify for inclusion. The idea of a 'contrib' directory
has been floated around for a while, I for one am against it for the same
reasons above - it should either be 100% supported or not included at all
IMO.
I think for the time being the best approach is for people to use their
own resources to publish contrib-type code on the web and just follow the
usual process of announcing it on the list.
Grisha
Re: svn commit: r290569 - /httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Posted by Jim Gallacher <jg...@sympatico.ca>.
Nicolas Lehuen wrote:
> Hi all,
>
> I'm sorry to have launched such a heated discussion.
Don't apologize. It's all good fun. :)
> I was experimenting
> with a SQLite implementation of sessions, and got something functional
> enough that I wanted to archive it so that we could come back to it
> later... I don't want it to distract us from the 3.2 release :).
We are in a waiting mode right now anyway. I'm ready to start talking
about 3.3.
> That being said, why SQLite ? Because it's simple to install and use (no
> administration required). You just give it a file name and you're ready
> to roll. Plus, I really wanted to experiment with SQLite :).
>
> I must confess that the current implementation seems 30% slower than
> FileSession, but we are not cluttering the filesystem (due to FS
> clusters, FileSession files all use a lot of disk space) and cleaning up
> old sessions is very fast (I used a DELETE FROM sessions WHERE ... just
> like Jim described), contrary to FileSession, so there is a tradeoff.
>
> Better performance could be achieved if we could use a connection pool.
> Unfortunately SQLite explicitely forbids about creating a connection in
> a thread and using it in another thread
> (http://www.sqlite.org/faq.html#q8). This means that the only connection
> pooling we can do is to associate a connection to a thread (maybe using
> a thread local). I'll give it a try later. Anyway, other DBMS clients
> usually don't have this particular limitation.
>
> As for a ANSI SQL-92 implementation, why not, but experience shows that
> ANSI SQL-92 only takes you so far. See the excellent article on
> http://troels.arvin.dk/db/rdbms/. This is complicated by discrepancies
> in the various DBAPI implementations which feature different ways of
> passing parameters (as of today I still don't understand why DBAPI
> allows for 4 different ways of passing parameters instead of only 1),
> escaping quotes, etc. If you have a look at SQLiteSession.py, you'll see
> that's it's very straightforward. Paradoxically, if you try to implement
> a generic SQLSession, you'll have a much more complicated code. I think
> it'll be easier to implement a Session subclass per DBMS.
I think we can have it both ways! Make a best effort to create a
SQLSession class that should work with most (many? some?) databases, but
move any code which interacts with the database to separate methods.
Pass a db connection as an optional __init__ paramater. If someone wants
to use a database which is not compatible, then they can create a
subclass with sql statements specific to their database. As a rough
sketch consider the following code for the do_save method.
class GenericSQLSession(BaseSession):
def __init__(self, req, filename=None, sid=0, secret=None,
timeout=0, lock=1, db=None):
if not db:
self._db = self._connect()
else:
self._db = db
... snip ...
def do_save(self, dict):
db = self._db
try:
try:
cur = db.cursor()
data = buffer(cPickle.dumps(dict,2))
timeout = self._accessed+self._timeout
self._execute_update(cur, self._sid, data, timeout)
db.commit()
finally:
cur.close()
finally:
db.close()
def _execute_update(self, cur, sid, data, timeout):
"""Override this method for database specific update or
insert statements
"""
cur.execute("""insert or replace into sessions (id,data,timeout)
values (?,?,?)""",
(self._sid,data,timeout))
def _connect(self):
""" override this for database specific connection"""
...
do database specific connection here
...
return db
Regards,
Jim
> Regards,
> Nicolas
>
>
> 2005/9/23, Jim Gallacher <jg.lists@sympatico.ca
> <ma...@sympatico.ca>>:
>
> Gregory (Grisha) Trubetskoy wrote:
>
> > I think it might be interesting to see something like an ANSI SQL-92
> > compatible session with some suggestions on how it can be easily
> > integrated with your database vendor of choice, but deifinitely not
> > support specific database vendors, except for those whose support
> exists
> > natively in the Python distribution (which is none at this point).
> >
> >>> and is this the path we want to take, or is there something about
> >>> sqlite that makes it unique?
> >
> >
> > ...so nothing unique about sqlite? If so, I don't think it should be
> > part of mod_python unless/until it is standard in Python, then we can
> > discuss it.
>
> Thinking about the session code, there is at least one big advantage to
> any SQL backend. One of the bottlenecks in both DbmSession and
> FileSession is in the expired session cleanup code.
>
> In DbmSession the cleanup code must iterate over *all* of the dbm
> records and unpickle each one to determine if the session data should be
> deleted. Needless to say this does not scale at all.
>
> FileSession is better or at least when the cleanup code runs it won't
> DOS the server. Again, we must iterate over all the session files to
> determine which ones have expired and should be deleted. I think I put
> some fairly clever things in there to make it scale, but I know it's not
> ideal.
>
> Contrast this with the cleanup for a SQL backend which would be as
> easy as:
> DELETE FROM sessions WHERE expires < current_time - timeout;
> assuming the sessions table has the expires and timeout fields updated
> from the session data when the db record is updated (or inserted).
>
> Thus a SQL backend would scale in a way that DbmSession or FileSession
> cannot. Granted, this is not unique to sqlite, but it is an argument for
> have some kind of sql session class.
>
> Regards,
> Jim
>
>
Re: svn commit: r290569 - /httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Posted by Nicolas Lehuen <ni...@gmail.com>.
Hi all,
I'm sorry to have launched such a heated discussion. I was experimenting
with a SQLite implementation of sessions, and got something functional
enough that I wanted to archive it so that we could come back to it later...
I don't want it to distract us from the 3.2 release :).
That being said, why SQLite ? Because it's simple to install and use (no
administration required). You just give it a file name and you're ready to
roll. Plus, I really wanted to experiment with SQLite :).
I must confess that the current implementation seems 30% slower than
FileSession, but we are not cluttering the filesystem (due to FS clusters,
FileSession files all use a lot of disk space) and cleaning up old sessions
is very fast (I used a DELETE FROM sessions WHERE ... just like Jim
described), contrary to FileSession, so there is a tradeoff.
Better performance could be achieved if we could use a connection pool.
Unfortunately SQLite explicitely forbids about creating a connection in a
thread and using it in another thread (http://www.sqlite.org/faq.html#q8).
This means that the only connection pooling we can do is to associate a
connection to a thread (maybe using a thread local). I'll give it a try
later. Anyway, other DBMS clients usually don't have this particular
limitation.
As for a ANSI SQL-92 implementation, why not, but experience shows that ANSI
SQL-92 only takes you so far. See the excellent article on
http://troels.arvin.dk/db/rdbms/. This is complicated by discrepancies in
the various DBAPI implementations which feature different ways of passing
parameters (as of today I still don't understand why DBAPI allows for 4
different ways of passing parameters instead of only 1), escaping quotes,
etc. If you have a look at SQLiteSession.py, you'll see that's it's very
straightforward. Paradoxically, if you try to implement a generic
SQLSession, you'll have a much more complicated code. I think it'll be
easier to implement a Session subclass per DBMS.
Regards,
Nicolas
2005/9/23, Jim Gallacher <jg...@sympatico.ca>:
>
> Gregory (Grisha) Trubetskoy wrote:
>
> > I think it might be interesting to see something like an ANSI SQL-92
> > compatible session with some suggestions on how it can be easily
> > integrated with your database vendor of choice, but deifinitely not
> > support specific database vendors, except for those whose support exists
> > natively in the Python distribution (which is none at this point).
> >
> >>> and is this the path we want to take, or is there something about
> >>> sqlite that makes it unique?
> >
> >
> > ...so nothing unique about sqlite? If so, I don't think it should be
> > part of mod_python unless/until it is standard in Python, then we can
> > discuss it.
>
> Thinking about the session code, there is at least one big advantage to
> any SQL backend. One of the bottlenecks in both DbmSession and
> FileSession is in the expired session cleanup code.
>
> In DbmSession the cleanup code must iterate over *all* of the dbm
> records and unpickle each one to determine if the session data should be
> deleted. Needless to say this does not scale at all.
>
> FileSession is better or at least when the cleanup code runs it won't
> DOS the server. Again, we must iterate over all the session files to
> determine which ones have expired and should be deleted. I think I put
> some fairly clever things in there to make it scale, but I know it's not
> ideal.
>
> Contrast this with the cleanup for a SQL backend which would be as easy
> as:
> DELETE FROM sessions WHERE expires < current_time - timeout;
> assuming the sessions table has the expires and timeout fields updated
> from the session data when the db record is updated (or inserted).
>
> Thus a SQL backend would scale in a way that DbmSession or FileSession
> cannot. Granted, this is not unique to sqlite, but it is an argument for
> have some kind of sql session class.
>
> Regards,
> Jim
>
Re: svn commit: r290569 - /httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Posted by Jim Gallacher <jg...@sympatico.ca>.
Gregory (Grisha) Trubetskoy wrote:
> I think it might be interesting to see something like an ANSI SQL-92
> compatible session with some suggestions on how it can be easily
> integrated with your database vendor of choice, but deifinitely not
> support specific database vendors, except for those whose support exists
> natively in the Python distribution (which is none at this point).
>
>>> and is this the path we want to take, or is there something about
>>> sqlite that makes it unique?
>
>
> ...so nothing unique about sqlite? If so, I don't think it should be
> part of mod_python unless/until it is standard in Python, then we can
> discuss it.
Thinking about the session code, there is at least one big advantage to
any SQL backend. One of the bottlenecks in both DbmSession and
FileSession is in the expired session cleanup code.
In DbmSession the cleanup code must iterate over *all* of the dbm
records and unpickle each one to determine if the session data should be
deleted. Needless to say this does not scale at all.
FileSession is better or at least when the cleanup code runs it won't
DOS the server. Again, we must iterate over all the session files to
determine which ones have expired and should be deleted. I think I put
some fairly clever things in there to make it scale, but I know it's not
ideal.
Contrast this with the cleanup for a SQL backend which would be as easy as:
DELETE FROM sessions WHERE expires < current_time - timeout;
assuming the sessions table has the expires and timeout fields updated
from the session data when the db record is updated (or inserted).
Thus a SQL backend would scale in a way that DbmSession or FileSession
cannot. Granted, this is not unique to sqlite, but it is an argument for
have some kind of sql session class.
Regards,
Jim
Re: svn commit: r290569 - /httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Thu, 22 Sep 2005, Jim Gallacher wrote:
> Gregory (Grisha) Trubetskoy wrote:
>>
>> OK, my next question would be - is MySQL, PostgreSQL, Informix, Oracle,
>> etc next,
>
> Yes. ;)
And how did we arrive at this decision? :-)
I'd be pretty strongly -1 on this, as it's got little to do with
Apache/Python integration which is our core mission.
I think it might be interesting to see something like an ANSI SQL-92
compatible session with some suggestions on how it can be easily
integrated with your database vendor of choice, but deifinitely not
support specific database vendors, except for those whose support exists
natively in the Python distribution (which is none at this point).
>> and is this the path we want to take, or is there something about sqlite
>> that makes it unique?
...so nothing unique about sqlite? If so, I don't think it should be part
of mod_python unless/until it is standard in Python, then we can discuss
it.
> I don't know if it is that path we *want* to take, but I think there is a
> certain inevitability that it's the path we *will* take.
We will take the path we want :-)
> I'm personally thinking about a MySQL backend, not because I need it but
> because I'm curious to compare the performance with FileSession.
But does this mean it has to be included in mod_python?
> The best approach might be to refactor Session.py to easily accommodate
> subclasses for other persistent stores.
That I can agree with. Not necessarily "Session.py" but rather the Session
class (inside Session.py). I remember that a lot of time/thought went into
it, so it's not like it's going to be a "no-brainer" though.
> Any new session subclasses get their own file eg.
>
> mod_python/sessions/sqlite.py
-1
> mod_python/sessions/mysql.py
-1
> The current Session.py could stay as is, or we could split FileSession,
> DbmSession and MemorySession into their own files
I think at this point it'd be cleaner to move the FileSession class into
the Session.py file rather than split into individual files. I'm not sure.
Something to ponder upon, I guess.
> and just have a stub in Session.py for backward compatability.
Not "backwards compatibility", but "default". Using Session should let you
use the session mechanism that is most recommended if you do not want to
think about it too much.
> On another note, if we are starting to roll with new features for 3.3 I would
> suggest we need to immediately create a new svn branch for 3.2 bugfixes.
Yes
Cheers,
Grisha
Re: svn commit: r290569 - /httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Posted by Jim Gallacher <jg...@sympatico.ca>.
Gregory (Grisha) Trubetskoy wrote:
>
> OK, my next question would be - is MySQL, PostgreSQL, Informix, Oracle,
> etc next,
Yes. ;)
> and is this the path we want to take, or is there something
> about sqlite that makes it unique?
>
I don't know if it is that path we *want* to take, but I think there is
a certain inevitability that it's the path we *will* take. I'm
personally thinking about a MySQL backend, not because I need it but
because I'm curious to compare the performance with FileSession.
The best approach might be to refactor Session.py to easily accommodate
subclasses for other persistent stores. Any new session subclasses get
their own file eg.
mod_python/sessions/sqlite.py
mod_python/sessions/mysql.py
That way there are no dependency problems in Session.py. If some code
imports sessions.sqlite and sqlite is not installed then let it raise an
exception as it should.
The current Session.py could stay as is, or we could split FileSession,
DbmSession and MemorySession into their own files and just have a stub
in Session.py for backward compatability. This reorganization may also
make it easier for users to create their own session subclasses.Related
to this, the current code for Session.Session only allows one of the
standard session classes to be specified by "PythonOption session". It
would be nice if it there was a way to make this more dynamic and the
refactoring might assist in this.
On another note, if we are starting to roll with new features for 3.3 I
would suggest we need to immediately create a new svn branch for 3.2
bugfixes.
Regards,
Jim
> On Thu, 22 Sep 2005, Robert Sanderson wrote:
>
>>
>>> Can we have a little discussion on pros/cons of this? Does this make
>>> mod_python dependent on sqlite?
>>
>>
>> Nope. It'll just silently fail if it can't import dbapi2.
>>
>> Rob
>>
>>>> +try:
>>>> + # If this code is included into Session.py,
>>>> + # we don't want to add a dependency to SQLite
>>>> + from pysqlite2 import dbapi2 as sqlite
>>>> +except:
>>>> + pass
>>>> +else:
>>>> + class SQLiteSession(BaseSession):
>>
>>
>
Re: svn commit: r290569 - /httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
OK, my next question would be - is MySQL, PostgreSQL, Informix, Oracle,
etc next, and is this the path we want to take, or is there something
about sqlite that makes it unique?
Grisha
On Thu, 22 Sep 2005, Robert Sanderson wrote:
>
>> Can we have a little discussion on pros/cons of this? Does this make
>> mod_python dependent on sqlite?
>
> Nope. It'll just silently fail if it can't import dbapi2.
>
> Rob
>
>>> +try:
>>> + # If this code is included into Session.py,
>>> + # we don't want to add a dependency to SQLite
>>> + from pysqlite2 import dbapi2 as sqlite
>>> +except:
>>> + pass
>>> +else:
>>> + class SQLiteSession(BaseSession):
>
Re: svn commit: r290569 - /httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Posted by Robert Sanderson <az...@liverpool.ac.uk>.
>Can we have a little discussion on pros/cons of this? Does this make
>mod_python dependent on sqlite?
Nope. It'll just silently fail if it can't import dbapi2.
Rob
>> +try:
>> + # If this code is included into Session.py,
>> + # we don't want to add a dependency to SQLite
>> + from pysqlite2 import dbapi2 as sqlite
>> +except:
>> + pass
>> +else:
>> + class SQLiteSession(BaseSession):
Re: svn commit: r290569 - /httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Can we have a little discussion on pros/cons of this? Does this make
mod_python dependent on sqlite?
Thanks,
Grisha
On Tue, 20 Sep 2005 nlehuen@apache.org wrote:
> Author: nlehuen
> Date: Tue Sep 20 14:28:32 2005
> New Revision: 290569
>
> URL: http://svn.apache.org/viewcvs?rev=290569&view=rev
> Log:
> A first try at implementing a session storage relying on SQLite. It is slower than FileSession but could scale better ?
>
> Added:
> httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
>
> Added: httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py
> URL: http://svn.apache.org/viewcvs/httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py?rev=290569&view=auto
> ==============================================================================
> --- httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py (added)
> +++ httpd/mod_python/trunk/lib/python/mod_python/SQLiteSession.py Tue Sep 20 14:28:32 2005
> @@ -0,0 +1,150 @@
> + #
> + # Copyright 2004 Apache Software Foundation
> + #
> + # Licensed under the Apache License, Version 2.0 (the "License"); you
> + # may not use this file except in compliance with the License. You
> + # may obtain a copy of the License at
> + #
> + # http://www.apache.org/licenses/LICENSE-2.0
> + #
> + # Unless required by applicable law or agreed to in writing, software
> + # distributed under the License is distributed on an "AS IS" BASIS,
> + # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> + # implied. See the License for the specific language governing
> + # permissions and limitations under the License.
> + #
> + # Originally developed by Gregory Trubetskoy.
> + #
> + # $Id: Session.py 231126 2005-08-09 22:26:38Z jgallacher $
> +from Session import *
> +from time import time
> +
> +try:
> + # If this code is included into Session.py,
> + # we don't want to add a dependency to SQLite
> + from pysqlite2 import dbapi2 as sqlite
> +except:
> + pass
> +else:
> + class SQLiteSession(BaseSession):
> + """ A session implementation using SQLite to store session data.
> + pysqlite2 is required, see http://pysqlite.org/
> + """
> +
> + def __init__(self, req, filename=None, sid=0, secret=None, timeout=0, lock=1):
> + # if no filename is given, get it from PythonOption
> + if not filename:
> + opts = req.get_options()
> + if opts.has_key("session_filename"):
> + filename = opts["session_filename"]
> + else:
> + # or build a session file in a temporary directory
> + filename = os.path.join(
> + opts.get('session_directory', tempdir),
> + 'mp_sess.sqlite'
> + )
> +
> + self.filename = filename
> +
> + # check whether the sessions table exists, and create it if not
> + db = sqlite.connect(self.filename)
> + try:
> + try:
> + cur = db.cursor()
> + cur.execute("""
> + select name from sqlite_master
> + where name='sessions' and type='table'
> + """)
> + if cur.fetchone() is None:
> + cur.execute("""
> + create table sessions
> + (id text,data blob,timeout real)
> + """)
> + cur.execute("""
> + create unique index idx_session on sessions (id)
> + """)
> + db.commit()
> + finally:
> + cur.close()
> + finally:
> + db.close()
> +
> + BaseSession.__init__(self, req, sid=sid, secret=secret,
> + timeout=timeout, lock=lock)
> +
> + def count(self):
> + db = sqlite.connect(self.filename)
> + try:
> + try:
> + cur = db.cursor()
> + cur.execute("select count(*) from sessions")
> + return cur.fetchone()[0]
> + finally:
> + cur.close()
> + finally:
> + db.close()
> +
> + def do_cleanup(self):
> + db = sqlite.connect(self.filename)
> + try:
> + try:
> + cur = db.cursor()
> + cur.execute(
> + "delete from sessions where timeout<?",
> + (time(),)
> + )
> + db.commit()
> + finally:
> + cur.close()
> + finally:
> + db.close()
> +
> + def do_load(self):
> + db = sqlite.connect(self.filename)
> + try:
> + try:
> + cur = db.cursor()
> + cur.execute(
> + "select data from sessions where id=?",
> + (self._sid,)
> + )
> + row = cur.fetchone()
> + if row is None:
> + return None
> + else:
> + return cPickle.loads(str(row[0]))
> + finally:
> + cur.close()
> + finally:
> + db.close()
> +
> + def do_save(self, dict):
> + db = sqlite.connect(self.filename)
> + try:
> + try:
> + cur = db.cursor()
> + data = buffer(cPickle.dumps(dict,2))
> + timeout = self._accessed+self._timeout
> + cur.execute("""
> + insert or replace into sessions (id,data,timeout)
> + values (?,?,?)
> + """,(self._sid,data,timeout))
> + db.commit()
> + finally:
> + cur.close()
> + finally:
> + db.close()
> +
> + def do_delete(self):
> + db = sqlite.connect(self.filename)
> + try:
> + try:
> + cur = db.cursor()
> + cur.execute(
> + "delete from sessions where id=?",
> + (self._sid,)
> + )
> + finally:
> + cur.close()
> + finally:
> + db.close()
>
>