[Zope] SQL Session v.0.1.1 released.

[Anthony Baxter]

At http://www.zope.org/Members/anthony/software/SQLSession/,
you'll find the first public release of my SQLSession Zope Product.

This product provides server-side sessions, backed by a SQL database
for storing all the data. 

Why would you use this? It's a way to replace passing all sorts of
junk around inside hidden fields, or (ick) inside lots of different
cookies.

Note that this is not the earlier SQL Session product I've mentioned
here in the past - after hacking around trying to do something that was
far far too fiddly, I came up with a cleaner solution and just wrote a
new one from scratch.

aaaanyway, the usual caveats apply - this is the first public 
release, if it eats your data, sets your cat on fire, and borrows 
the car without asking, don't come crying to me. (but send patches).

readme from the release follows.

Have fun, let me know if this is useful to you, and suggestions/fixes/&c.

Anthony

-------
README for SQL Session, v 0.1.1

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

        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',
	  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


	From here on inside the document, you can do things like

	<dtml-var "SESSION.set('someitem', 'somevalue')">

	<dtml-var "SESSION['someitem']">

	and it will just be squirrelled away in the DB.


    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 does
	no caching of results, and is, in fact, almost entirely stupid.
	It really should have some simple amounts of caching of lookups.

	(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!


    To Do:

	* Housekeeping.

	Right now the SQL Session as is does no housekeeping of the DB
	itself. I would _suggest_ that this would be something that people
	would do on a case by case basis. What you could do is put an
	extra column in the session table, like 'expires' or some such,
	set to 'now' + 30 minutes, then have something go through and
	nuke the data. It's probably not something to put inside Zope -
	unless the Scheduler re-appears.

	* Cookie Expiry.

	Yeah, yeah, the cookie needs to expire. Next version.

	* More testing.

	It's been, ahem, lightly tested. It Works For Me. Your Mileage May
	Vary.

	* Fix Bugs, add features, all that stuff.

	Whatever.


Anthony Baxter <anthony@interlink.com.au>, Fri Oct 22 01:22:44 EST 1999

-------

--
Anthony Baxter     <anthony@interlink.com.au>
It's never too late to have a happy childhood.