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

[Franz Holzinger]

Martin Kutschker a écrit :
> Steffen Kamper schrieb:
>> "Martin Kutschker" <martin.kutschker-n0spam at no5pam-blackbox.net> 
>> schrieb im Newsbeitrag 
>> news:mailman.1.1175458083.11183.typo3-dev at lists.netfielders.de...
>>> Steffen Kamper schrieb:
>>>> "Dmitry Dulepov" <9f4eetb02 at sneakemail.com> schrieb im Newsbeitrag 
>>>> news:mailman.1.1175173443.25187.typo3-dev at lists.netfielders.de...
>>>>> Hi!
>>>>>
>>>>> From time to time I see that people try to use 
>>>>> $TSFE->set_no_cache() in extensions. You know what happens next: no 
>>>>> caching for pages, performance is terrible, web server is not 
>>>>> responding, etc. At the same time, sometimes, in really rare cases 
>>>>> caching must be disabled. But definitely not this way from extensions.
>>>>>
>>>>> Should we change this function in some way? Should it explain 
>>>>> people that using it is no-good?
>>>>>
>>>>> Personally I would vote for radical methods like (1) keeping it but 
>>>>> emptying or (2) writing commented phrase inside generated FE page 
>>>>> that set_no_cache was used, so do not expect good performance.
>>>>>
>>>>> Any other ideas/opinions?
>>>>>
>>>>> -- 
>>>>> Dmitry Dulepov
>>>>>
>>>>> Web: http://typo3bloke.net/
>>>>> Skype: callto:liels_bugs
>>>>>
>>>>> "It is our choices, that show what we truly are,
>>>>> far more than our abilities." (A.P.W.B.D.)
>>>> 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?
>>>
>>> Masi
>>>
>>
>> hi Masi,
>>
>> sounds interesting, i'm not sure how this can be handled. Storing 
>> search results in a session is quite easy, but how do you present this 
>> on pages ?
>> Storing search result in tables may be a good idea, but it sounds 
>> nearly same like creating cHashes for piVar-combinations.
>>
>> Can you give us a deeper thought of this ?
> 
> For displaying the search result you need a USER_INT (possibly a 
> USER_INT within a USER) so that no cHashes are needed. Cached are only 
> the raw data, not the formatted output of the search. I don't think this 
> is a big problem as a search result is usually shorted lived.

I still wonder how this should work.
I have seen this link which has contents copied from a book by Dmitry 
Dulepov:

http://www.wiki-oblady.com/index.php/Appeler_un_plugin_en_USER_INT_dans_un_plugin_en_USER

But does this really work? When a USER object is cached, then normally 
the plugin is not called any more. But how should the USER_INT part of a 
USER object be changed then?
Maybe it has always to be one USER object called by a USER_INT object.

> The point is that you create from the search query (piVars) a key for 
> the search result. Whenever the PI has to show a result it will look it 
> up in the search cache. In this cache only the ids of the found rows are 
> stored (sorted!).
How do you implement a search cache?


- Franz