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.