Jeff AA wrote: > Agreed, but he wasn't talking about storing the results, just the query > parameters and current offset / number of rows, which is a-ok for > putting into a session.
No, that's exactly what ISN'T okay for putting into a session. If a user opens two browser windows, does a search in each, and then pages forward in each set of results, he will get completely wrong pages if you do this. The query parameters from the first search will be written over and lost. > Don't forget that you can have multiple sessions - store the query > params in a session identified by a query_id so that subsequent requests > just say something like: <A > HREF='/search&query_id=123456789&action=next'>Next</A> You could do that, with a unique ID for each set of parameters, but you might as well just put the parameters right in the link unless they're very long. > Don't mix transient query sessions with a User Session that stores info > about the user's logged in state etc. It would be normal for one user to > have multiple queries in a login session Hold on, I think we actually agree, but you're using the word session for a bunch of different things. What you're saying here sounds like the opposite of what you said above. In common usage, a session is the state of the user's interaction with the application. A cache of query data would be something else. > Or even to use a database that has a decent approach to caching. MySQL > promises automatic cacheable paged queries in the near future. And if > you write your own DB cache, you then need to manage the DB / cache > synch issues, cache size, cache expiry etc etc issues. Good cache is > very hard to do! better to get it from a real data bank. MySQL is fast, but usually not as fast as simple disk access. Cache::Cache and Cache::Mmap handle the details of the cache stuff for you, making it pretty easy. - Perrin
