Jump to content
Sign in to follow this  
fatkatie

use of $_SESSION[] space

Recommended Posts

I have search results which I wish to make 'sticky'  The size isn't large, say 100 lines of 40 characters each.

 

It's so easy to save it in the session but I wonder... is it a wise thing to do?

 

I use the $_SESSION variable with many things; user login values and site options, and things like that.  This would be a new use for me.

 

Comments?  Thanks

 

php mysql goddady unix share

 

 

Share this post


Link to post
Share on other sites

I'm not entirely clear on what you want to get when you say "sticky".

 

What is the user experience you want to get?

Share this post


Link to post
Share on other sites

In this instance, when ever a successful search is executed, a new navigation button is included in the menu.  It says something like 'Last Successful Search'.  The existence of this link is based on the status of the $_SESSION var holding the last search info.

 

Selecting the link brings one to a page that does nothing but display that  last search result.  The data is read from the $_SESSION['search] var which contains an array of text results.

 

The next successful search replaces the information.

Share this post


Link to post
Share on other sites

Think about how much data you'll be storing in the session - the more you put in there, the slower pages will load. So this is only suitable if you don't have to store "much" (and how much that is you'll have to decide for yourself).

 

But yes, you can: do the search the first time, store the results in the session, then display the button if there is anything stored.

 

If you have potentially a lot of results then putting it in the session isn't the right approach. Better would be either store the search query and replay that each time. Or if you wanted to save the results, like if they might change and you want to show the original results, then cache the results in your database somewhere with a particular ID and you put that ID into the session.

  • Like 1

Share this post


Link to post
Share on other sites

You're helpful as always.  I don't have a handle on the impact of session use.  I would have thought a query replay would be

the worst thing you could do... but that's an impression.  I have no idea.  I have noticed that sql runs very fast on godaddy.

There is also a memory allocation you get.  You can upgrade, but an economy unix share gets half meg.  

 

When you say store the search query, do you mean as a stored procedure, stored prepared statement or, literally, the select text?

 

Thanks again.

Share this post


Link to post
Share on other sites

I don't have a handle on the impact of session use.

It isn't that precise to begin with. Sessions are generally driven by files; when PHP loads up a session it reads the file, interprets what's inside, then restores it as $_SESSION. Then when the request is done it can/might save the session data back into that file.

Naturally, adding more data means PHP will take a bit longer to read the file (start the session) and finish the request (save the session). It's all still quite fast so you don't have to worry about every single value you put in there, but you might actually notice a performance impact if you were to store, say, 1000 search results. It's not like you need those results on every page - just that there are results, then only on the search page do you need to get them all.

 

I would have thought a query replay would be the worst thing you could do...

It's all about trade-offs. By storing the query you have less in the session but loading the search page means doing the search over again. By storing the results you have all that available immediately but you do have to store it all.

 

Consider how fast the query is, how many results there are on average, how much data it takes to "remember" those results (ie, if you put them in the session), and how often the search page will be revisited.

 

There's also another thing to consider: if you change the code in the future. If someone visits your site and gets a session, then you change your code, and they come back, they will still be using the old session. So if that code you change involves session code you need to be prepared to handle "old" sessions. It can get trickier if you stop storing some data but don't ever clean it up.

For example, if you originally stored the search results but decided to store the query, the code would probably work fine because old users don't have a query stored, but if they have search results stored then those will stick around and get loaded/unloaded with every page until the session naturally expires.

 

But that's applicable to anything involving sessions, not just this.

 

When you say store the search query, do you mean as a stored procedure, stored prepared statement or, literally, the select text?

Personally I would store the search parameters. Not the SELECT query itself but the information they entered in the search form. So the search text and whatever else you prompt for (eg, type of thing to search for, or places to search in). The code then takes that search information and continues from there.

Alternatively you store the search query. Alternatively alternatively you'd store the search results.

 

Whatever approach, the change to the code is about the same.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.