PHP Sessions are similar to session in ASP, ASP.Net, etc. Objects within the session are serialised into a stream and stored in the specified storage medium. By Default, PHP stores sessions in a file in the /tmp directory, identified by a unique filename that is stored in a cookie on the browser if it is supported, or encoded onto the URL if not.
You can also write custom session handlers, allowing you to store the session anywhere else including a database. There is some documentation on the Zend.com site for using the Session api, but it's simply a matter of writing some functions with specific names, and hooking them in via the php configuration. As far as storing a memory database, you would need to somehow grab a handle to the memory location, keep the database alive between session hits, and then re-attach to it. Alternatively you could create some kind of database serialisation method and serialise the database to the session. It would, however, be a lot more efficient to simply create a file-based database in the first place and re-open it every time a page is called. Hope this helps, Robert Foster General Manager Mountain Visions P/L http://mountainvisions.com.au Serialised is spelt with an 's', not a 'z' (I'm Australian) -----Original Message----- From: Kervin L. Pierre [mailto:[EMAIL PROTECTED] Sent: Wednesday, 15 February 2006 7:01 AM To: sqlite-users@sqlite.org Subject: Re: [sqlite] :memory: and sessions with PHP Hello, I think the problem is that PHP uses a file-based session serialization. Therefore anything that cannot be saved to a file and returned ( eg. you can't do this with file handles, etc. ) cannot be saved in session scope in PHP as it is implemented by default. There is the 'mm' extension ( search for reference on http://us3.php.net/session ) that is suppose to fix this, I've heard. Also, there is word that there will be memory based session in future versions PHP engine by default. I have never used 'mm'. So, your problem is that you have no place to put your SQLite handle after a script has finished executing, so that the next instance of the script can get it. PHP has no such scope by default. Best Regards, Kervin CrazyChris wrote: > We may be at crossed paths... I'm wanting to save the :memory: > database to the session, not the other way round, so that when the 2nd > page loads, the > :memory: database can be recreated and available as it was on the last > page load. The advantage is that after some time, the session is > deleted automatically by the server and the database goes with it, so > short term, high-intensity data can be stored and queried quickly in > :memory: and the add/edits remain through the entire user experience. > An alternative is to use a file based database per user, but this > would require a tidy-up routine to be manually coded, and makes the code less portable. > > An alternative is to create the :memory: database and populate it from > session data each time, then save back to session on script close. Not > as swift or elegant, but if it's the only way then that may be that! > > > > --- > > >>Hi there, >> >>I have a need to create a :memory: sqlite database, but save it into >>the user session (PHP) but can't see a way to access the data to save. >>Looking for a sqlite version of serialize() I guess. >> >>Has anyone managed to do this? Is it even possible? >> >>Wanting to be able to maintain a large chunk of data across a users > > session > >>on a website, and the array's are getting tedious to manage and search >>through! > > > The PHP session information has to be persistent, so it's not going to > be easy to use a :memory: database. There is lots of information > about how to save session information to a database, though, on the > PHP web site. I haven't looked at it in a couple of years, but I'd > guess that you'll get some good pointers if you look at the > documentation for session_set_save_handler(). > > Also, IIRC, PHP provides functions to do serialization. You won't > need them if you go the session_set_save_handler() route, but if you > want to serialize data yourself, those functions should be available. > > Derrell > >
