in reply to Database searches with persistent results via CGI

This is a mistake that many beginning web developers make. In fact, I have recently seen some outrageously paid Java consultants make the same mistake.

Users can -- and do -- open multiple browser windows when working with your site. A session ID stored in a cookie is global to all browser windows. This means that if a user has two windows open with different searches going in them, paging trough the results will not work. One search will overwrite the other.

The right way to cache results is to do it based on the actual search input. Previous posters discussed how to do it, so I'm just adding a why.

Of course you will probably need to find a new search method soon if you're using a SQL "LIKE" clause to implement it, but at least caching will make paging through results reasonably fast.

  • Comment on Store results by search term, not session ID

Replies are listed 'Best First'.
Re: Store results by search term, not session ID
by MrCromeDome (Deacon) on May 09, 2002 at 21:21 UTC
    If drive space is not an issue on the database server, is there harm in making a temp table in the following format?

    - search criteria
    - result column 1
    - result column 2
    . . .

    The reason I ask being that my search results will always have the same column names and ordering.

    And, as for storing the criteria in the table, I imagine I can consolidate it into some sort of string like:

    then index that field, consolidate a query into that format, and see if I get a match in the database? If not, cache some more data?

    Thanks for the help thus far :)

      Hmmm... I had a reply node here and it seems to have been erased when I replied to ask below in the same thread. Very strange.

      Anyway, the gist of it was that you can use the table structure you suggested or serialize the whole result data structure into a blob column using Storable.

      Also, make if your search criteria are in a hash make sure you sort them before you use them as the result key. Hashes can return their keys in a different order, even when the keys are identical.

Re: Store results by search term, not session ID
by ask (Pilgrim) on May 10, 2002 at 03:11 UTC
    I am amazed that noone else suggested that. Sites using session ids to make searches faster sucks. Blah!

     - ask

    ask bjoern hansen,   !try; do();
      Yeah, when these Java consultants did that in a search they built for the company I work for, I was amazed. I called them on their mistake and they first claimed it wasn't a problem and then claimed that it was our fault for not specifying in the contract that they had to support multiple browser windows! (The old "spec was bad" defense.)

      I think the problem in their case came from how much the Java servlet session interface looks like a cache. It's very tempting to just cache things in it rather than build your own proper cache. This is something to be wary of with Apache::Session too.

      (Incidentally, some of the other posters did mention the idea of using the search terms instead of the session. They just weren't as clear about why.)