Project

General

Profile

Actions

Feature #30006

closed

Allow manual pruning of caching framework entries

Added by Xavier Perseguers about 13 years ago. Updated about 13 years ago.

Status:
Rejected
Priority:
Should have
Assignee:
-
Category:
Caching
Target version:
-
Start date:
2011-09-19
Due date:
% Done:

0%

Estimated time:
PHP Version:
5.3
Tags:
Complexity:
easy
Sprint Focus:

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

30006.diff (3.12 KB) 30006.diff Xavier Perseguers, 2011-09-19 10:06
Actions #1

Updated by Xavier Perseguers about 13 years ago

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,
        )
);
Actions #3

Updated by Christian Kuhn about 13 years ago

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

Actions #4

Updated by Xavier Perseguers about 13 years ago

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!

Actions #5

Updated by Christian Kuhn about 13 years ago

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.

Actions #6

Updated by Xavier Perseguers about 13 years ago

Very good idea! Thanks.

Actions #7

Updated by Xavier Perseguers about 13 years ago

  • Assignee deleted (Xavier Perseguers)
Actions #8

Updated by Oliver Hader about 13 years ago

  • Status changed from New to Needs Feedback
  • PHP Version set to 5.3
Actions #9

Updated by Oliver Hader about 13 years ago

  • Target version changed from 4.6.0-beta3 to 4.6.0-RC1
Actions #10

Updated by Xavier Perseguers about 13 years ago

  • Status changed from Needs Feedback to Rejected
  • Target version deleted (4.6.0-RC1)

Subclassing the frontend class just work as it should

Actions

Also available in: Atom PDF