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):
