[TYPO3-v4] Clear all caches clears caching framework tables

[Christian Kuhn]

Hey Xavier

good to read you :)

On 09/12/2011 07:19 PM, Xavier Perseguers wrote:
> I have such an extension where I use the caching framework to easily...
> cache external data from a Web Service and I implemented a scheduler
> task to use one of the service entry point that gives me back the list
> of changes since a given point of time, allowing me to actively "flush"
> old entries.

Nice use case :) Do you use tagging to drop the entries you wish to 
invalidate?


> With the introduction of flush with clear all caches, anybody with the
> right to clear caches blindly flushes all caches.

That was kind of the goal ;)


> 1) That's my problem (as extension developer) and I better should
> reinvent the wheel and create my own dedicated caching tables (not
> complicated, I know)

The 'clear all cache' backend functionality asks the cacheManager for 
*all* registered caches and flushes them, so it is probably not really 
easy to circumvent this without a core patch if you want to use the rest 
of the cf API.


> 2) We add an option to prevent some caching tables to be flushed
> automatically, this is then as before (but not active by default of
> course) where one has to take care of it

Short answer:
We *can* easily solve this problem for 4.6, but this part is a bit of 
work-in-progress and we will probably come up with a better approach for 
this problem with 4.7 anyway.


Long answer:
It would be pretty easy to add a 'clear blackList' configuration option 
for specific caches.
At the moment I am just a bit unsure on where to put it: I don't want to 
pollute Typo3ConfVars globals-sys-cachingframework for this, especially 
since this is in sync with flow3. Actually I've worked hard for 4.6 to 
streamline and simplify the config options as much as possible and don't 
really like the idea to add some new option that is just used in tcemain 
'clearAllCache' code. Maybe it fits better if we add a pageTs / userTS 
option for this (similar to the good old clearCacheCmd option).


For the bigger picture:
We are not done with the cache refactoring, and I plan to continue with 4.7:

There are still caches that are hard coded, like the treelist thing 
(rootline cache and this nasty menu cache where we have this long 
standing cache issues). Those in-deep-core caches are aimed to be 
tackled with 4.7.

We've now introduced new caches like the phpCode, the l10n cache and the 
runtime cache. While cache_pages and l10n are specific caches for _this_ 
purpose, runtime and phpCode are more 'general' caches, its 
characteristics are defined by the used backend (runtime = exists for 
this request but can take different things, phpcode = a cache to stuff 
executable php code into). So we have basically two different scopes 
(btw: this section is not complete in the wiki) and I'm not really sure 
on how to solve this generally. I'm already thinking about some 'cache 
routing' middleware class for this. And this class could be the point 
where things like cache clearing characteristics could be defined as 
well. Example: If I want to get rid of autoload cache entries, I drop by 
tag in phpCode cache, if I want to get rid of l10n entries, I flush l10n 
cache, same for pages. Additionally some things are still not settled in 
FLOW3 in this reagard, for example there are backend that are capable of 
proper tagging, while others are not. At the moment I'm a bit stuck in 
thinking about a cool solution for this and I need some counterpart to 
discuss possible solutions, I have ideas but did not find 'the solution' 
until now.
Furthermore I don't really like the bloating 'clear cache' drop-down in 
the backend, we currently have up to 5(!) options by default. We imho 
need some better abstraction for this.

So, I'd personally prefer to not add some option for 4.6 to solve your 
issue because we get a real solution with 4.7 anyway and I would like to 
spare the effort of taking care of a backwards compatible problem we 
might introduce with a specific minor problem solution we add during end 
of 4.6 development. If however we decide to still introduce something 
like this for 4.6, we might want to mark it as temporary option that 
might change for 4.7 again.


Glad about your feedback.


Regards
Christian