I was thinking of having a table that goes like:

session_id     var_name     value   
----------------------------------------
asdijhufio4    user_id      1
asdijhufio4    state        55
fddffff0012    new_user     1
dfdfgeret44    username     'bob'
[download]

I would think the performance of this would be a lot better than the way you serialize your data.

Update:It is possible to store the hash in a MySQL blob using \0 as a seperator. This may work better if you don't want to have multiple rows per session.

Hope this helps...

gav^

While a method like this is pretty commonly used in home rolled session systems (and works well enough), there is something that Apache::Session allows you to do via using Storable that you can't do with this mechanism.

Arbitrary data structures.

What happens when the session information I need to store goes beyond simple key value pairs? What if I have something like:

# assume $session is via Apache::Session 
$session->{'email_targets'} = {
"john@doe.com" => {
                    'first_name' => 'John',
                    'last_name'  => 'Doe'
                   },
"jane@doe.com" => {
                    'first_name' => 'Jane',
                    'last_name'  => 'Doe'
                  }
};
[download]

HTH

/\/\averick
perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

Accepted - the fact that Apache::Session uses Storable to store deep structures is a stumbling block of course. However what is the benefit? In the What are some things to remember? section your document says:

Only use a single level associative array or hash. Do not try to use multiple levels in PHP, such as $session['username'][1], or use references in Perl, as in $session{username}[2]. Only store numerical and string data in session variables.

Makeshifts last the longest.

That is only when using sessions between php and perl. For web applications that use only perl, there is no need to worry about it, and the full power of Storable can be unleased.

Makeshifts last the longest.