Feature #30006
closed
Allow manual pruning of caching framework entries
Added by Xavier Perseguers about 13 years ago.
Updated about 13 years ago.
Description
In TYPO3 4.6, caching tables are automatically flushed when using the menu entry "Clear all caches". At first glance, it makes sense but extension authors may have chosen to take advantage of the caching framework to build real-life application caches and expect the caching framework to let them handle pruning of outdated data.
Example for this is the egovapi extension which retrieves governmental information from a web service and caches them locally. Another web service endpoint returns list of recently updated data, effectively allowing the local cache to be actively flushed (typically by tags).
At the moment, the typical clear all caches call defects the clever caching that was implemented and worked in TYPO3 4.5 due to the lack of integrate cache pruning.
Files
Proposal:
Add an option in caching configuration to declare the backend to be manually handled:
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['egovapi'] = array(
'backend' => 't3lib_cache_backend_DbBackend',
'options' => array(
'manualFlush' => TRUE,
)
);
Hey Xavier,
I thought about your issue as well since you raised it in the v4 list. Your solution is one option, and another one would be to handle this in the cacheManager class with a hook or something. In any case we should synchronize this with FLOW3, they might have the same issue. I'll trigger the FLOW3 team in this regard.
Christian
Hey Christian,
Thanks for the information. I know you did not forget about it, I just wanted to raise the awareness of this to the whole community because I'd like to integrate this "final" change into beta3, tomorrow.
Having a hook is fine as well of course and would even be slightly better since it allows even finer tuning and is more in line with our policy not to introduce new features after freeze (a hook being NOT considered as a new feature in our policy).
As you see, I linked to my own problem in egovapi, I may implement whichever solution for testing right away!
Another idea that would work without any changes:
You create an own frontend that overwrites flush():
flush() {
if (func_get_args === 0) {
noop();
} else {
if ($param1 === 'really-flush') {
parent::flush();
}
}
}
This way flush() would do nothing if you do not add some special parameter.
This might be a bit hacky, but it could be a solution until we come up with some serious solution from FLOW3.
- Assignee deleted (
Xavier Perseguers)
- Status changed from New to Needs Feedback
- PHP Version set to 5.3
- Target version changed from 4.6.0-beta3 to 4.6.0-RC1
- Status changed from Needs Feedback to Rejected
- Target version deleted (
4.6.0-RC1)
Subclassing the frontend class just work as it should
Also available in: Atom
PDF