[TYPO3-dev] set_no_cache is bad. What's next?

[Martin Kutschker]

Ernesto Baschny [cron IT] schrieb:
> Martin Kutschker wrote: on 01.04.2007 22:08:
> 
>>> Ok, here i have a question for a special case, and alos an example,
>>> that shows the difficults of right caching:
>>>
>>> On a list-view with a form, that filters the records, what is the best
>>> technique that the search results will be cached ?
> 
>> Store the search result somewhere. Possible locations are the session or
>> a table. If you use a table you can share the results of popular
>> searches across sessions.
>>
>> I thought about creating this for the indexed search. and I even thought
>> about making a framework for other extensions. Maybe this is something
>> for ECT?
> 
> Yes, that would be definitively a huge performance boost. Especially for
> browsing through pages in a search result list and have that search
> results already cached.
> 
> So go for it, Martin! :)
> 
> Basically we need something like cache_hash "enhanced" where we also
> count "hits", "last used timestamp", so that we can automatically clean
> up old or unused cache entries and just keep the "fresh" and "mostly
> used" stuff in cache. This doesn't need to be specific for search
> results, but for any information that we might want to cache, but where
> we don't want the risk of polluting our tables with infinite number of
> entries.

Yes, of course. I think this data must be stored:

normalized query
timestamp (creation time and last time used for shared cache)
session id (if a private cache)
hit count
hits (either as a list, a serialized array or in a separate table)

With a normalized query I mean the list of query parameters in a fixed 
order so the search can be retrieved from cache. May be done with a 
hash, but still the query should be normalized.

If access control comes into play it the search result may either be 
forced to be private or maybe some session info can be attached to the 
search result (a list of ids not to be shown).

Masi