Each catalog may maintain a search cache, which is enabled by specifying
Yes for the SearchCache directive in catalog.cfg. It operates by developing a
MD5 key or 3-byte checksum of the combined parameters
of a search.
If your catalog frequently specifies category searches in a large catalog, speed of search return can be increased by a large factor, mostly by obviating the need for database lookups.
If you have mostly dynamic session-based content based on user variables, you should not use SearchCache unless you want to give that up. MiniVend will not cache pages with dynamic content, and using cache slows down searches that don't cache.
If you have the MD5 module installed on Perl, it will be used to generate the cache keys. This will guarantee a unique cache ID. If you don't have MD5 installed, a 32-bit checksum will be used to create the cache key. It is conceivable, indeed likely in a large catalog, that two separate searches could generate the same 32-bit checksum and return the same cached search.
The search cache is invalidated when a user hits
``RELOAD''. It can also be invalidated by a [set mv_no_cache]1[/set] scratch setting, which only takes effect for the next page.
If you change your product database or any other files you search, you should reconfigure or the search returns may be wrong. You also may just remove all files in the tmp/ directory.
Search caching is disabled on a client-by-client basis if the client browser does not have cookie capability, for the generated session numbers would be incorrect otherwise.
Multiple page returns are also cached. If you [set mv_no_count]1[/set]
on the calling page, then the user's browser will keep track of the
traveled links.
The last search can be recalled with [page href="[data session last_search]"].