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
