Software Product:
Server-Side Session with SQL DB support
Created by anthony.
Last modified on 1999/12/14.
README for SQL Session, v 0.2.3
SQL Session
This is a server-side session object that stores all state in
an SQL database.
Usage:
create an SQL Session object (it will be called 'Session'), and
make sure the SQL is correct.
in all documents that want to use Sessions, put, at the top
<dtml-call Session>
(I'd suggest putting it in your standard_html_header)
This does a few things:
It looks for a session cookie (by default called _ZSession, but
that's something you can just set). If it finds one, it looks in
the database to check that this is an ok cookie to use.
If it doesn't find a cookie, or it finds that the Session is a
dud, or if the request has the parameter '_force_new_session' set
to a true value, it will create a new Session in the DB, then send
back a cookie with that session in it.
Next, it creates a SessionObj called 'SESSION', and puts it
in the REQUEST object (so REQUEST['SESSION'] - just like
REQUEST['RESPONSE']). This looks and acts like a dictionary,
only it pulls its data out of the DB, and sets data in the
DB. It supports the following:
__getitem__, __setitem__, set, keys, values, items, and most
other dictionary methods (except copy)
From here on inside the document, you can do things like
<dtml-call "SESSION.set('someitem', 'somevalue')">
<dtml-var "SESSION['someitem']">
and it will just be squirrelled away in the DB.
Session can also be called with an argument of session_id. If
set, this is the name of the session to use.
It can also be called with a couple of flags: noCookie
will stop the code setting a cookie, while validSession
will raise an exception if the session being requested
does not already exist.
SESSION now supports the method 'getName()' - this returns
the name of the current session.
The Gory Details, #1: SQL schema:
The default SQL schema is pretty dumb, but it should
work on everything (I test on gadfly).
create table sessions
( session varchar )
create unique index sessions_idx on sessions(session)
create table session_data
( session varchar,
name varchar,
value varchar )
A smarter one (like the one I use :) would use a sequence or
similar to create a session_id, and use that in a key in session_data.
Anyway, you don't have to use this schema - go edit the sql methods
in the session (pull up it's management interface).
The Gory Details, #2: Storing objects:
Right now the SessionObj stores base64 encoded pickles. It can
optionally do caching of results, but only for the lifetime of the
REQUEST.
(sessionObjs are created for each request, so they don't have to
worry about getting out of sync with the db.)
The nice thing about storing things this way is, of course,
that you can stuff almost anything into it. The bad thing is,
of course, that you can stuff almost anything into it. Make sure
your definition of the session_data table makes the value column
sufficiently large for your needs!
Note that some databases gripe about inserting varchars as literal
strings with newlines in them. For these, you should use the
'base64oneline' encoding format. (select it from the main edit window).
Anthony Baxter <anthony@interlink.com.au>, Sun Nov 21 17:58:02 EST 1999
License: OpenSource
Download
|
