When debugging PHPLIB applications, it is often useful to be able to read and understand the contents of the active_sessions table. Each session is represented by a single line in this table. The primary key to this table is the pair name and sid. name is the content of $this->name and is usually the classname of your session class. sid is the content of $this->id and is usually the MD5 hash of a uniqid and some magic string.

By choosing a pair, it is possible for PHPLIB to have more than one session type (for example, session and user data, see the User class below) per application and store all this data in a single table. If you are debugging a session class, for example Example_Session, only records where name = "Example_Session" are of interest to you. Determine the current session id of your Example_Session by printing $sess->id and select the record with that name and sid from the database.

The changed field indicates when this record has been updated the last time. It is a 14 character (Y2K compliant) string of the format YYYYMMDDhhmmss. Ordering by changed desc will show you the most current session records first (the MySQL "limit" clause may come in handy here).

The val column of a session record contains a PHP program that can be safely fed to stripslashes() first and eval() after that. The PHP program consists entirely of assignments and contains all instructions necessary to recreate the persistent variables. The structure and order of instructions within this program is always the same.

First item is always an assignment to $this->in. If set to 1, auto_init has been executed by this session. If not set to 1, auto_init has not been executed, yet. This may be because no auto_init file is defined for that session.

After that comes code like this: $this->pt = array(); followed by a bunch of assignments like $this->pt["somestring"] = 1;. Each somestring is the name of a registered variable. Variable registrations are persistent themselves and are saved with the $this->pt array. Even if the variable in question is not set, it may be registered and stays so until it is unregistered or the session is deleted. Check the contents of the pt array is you want to see which variables are currently registered with your session.

Finally, the actual contents of your variables are saved. This is always done by accessing the $GLOBALS array and always by enumerating the scalar values that make up the persistent variable. For a scalar, you will see code like $GLOBALS[somevar] = "value";.

For an array, first $GLOBALS[someary] = array(); is generated. Then the scalars that make up the array, if any, are written out, generating code that looks like $GLOBALS[someary][index] = "value".

And for objects, code to create an object instance is saved: $GLOBALS[someobj] = new Classname;. "Classname" is taken from the objects $classname slot, which must be present and accurate. Then the scalars that are to be saved are written out, according to the contents of the objects persistent_slots array: $GLOBALS[someobj]->slot = "value"; is written.

If you want to see what values have been saved to the database, you just have to look at the $GLOBALS assignments for that session.