[TYPO3-core] RFC #15937: Bug: [Caching framework] Improve error message if no frontend was defined for core caches

[Ernesto Baschny [cron IT]]

Christian Kuhn schrieb am 26.10.2010 23:12:
> Hey,
> 
> On 10/26/2010 11:13 AM, Ernesto Baschny [cron IT] wrote:
>> I would go the way of saying this is then a problem of extbase. The
>> caching framework API should specify that any caches should be
>> registered at "init" time (ext_localconf.php) so that everyone knows
>> about them and now only on "first usage".
>>
>> Registering a cache early to the manager does not impose such a
>> performance penalty, does it?
> 
> Yes, in fact it's not that much of an overhead. But it does produce
> unneeded overhead, take a site with 1k pages and extbase (or tt_news, or
> some other ext using the cf) being used only on a small number of pages.
> You'll get several class instances and (more important) a lot of unused
> connections to backend storages for each and every (FE) call.
> This just isn't smart. Caches should be used and instantiated when they
> are needed and the cache manager is designed to handle this in a nice way.
> 
> What's wrong with just declaring all possible caches in TYPO3_CONF_VARS
> and use them when needed? We just need logic to throw meaningful error
> messages if the declaration is not complete.

Nothing wrong, but it doesn't look like a documented API for creating a
new cache (yet).

If the configuration is required anyway, we shouldn't allow the
flexibility of creating the cache with the cacheFactory later with a
flexible set of parameters.

E.g. first this "configuration" is declared in ext_localconf.php:

$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_extbase_reflection']
= array(
        'frontend' => 't3lib_cache_frontend_VariableFrontend',
        'backend' => 't3lib_cache_backend_DbBackend',
        'options' => array(
                'cacheTable' => 'tx_extbase_cache_reflection',
                'tagsTable' => 'tx_extbase_cache_reflection_tags',
        ),
);

Later on the cache is initialized with:

$GLOBALS['typo3CacheFactory']->create(
	'cache_extbase_reflection',
	$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_extbase_reflection']['frontend'],
	$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_extbase_reflection']['backend'],
	$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_extbase_reflection']['options']
);

See the redundancy? You have to pass again the configuration options.
The API doesn't mandate the arguments to be exactly these
$TYPO3_CONF_VARS settings. This is also the reason why you could not
rely on it until now. You cannot guarantee that extensions pass exactly
these parameters. This is only a convention until now, because the
examples are set up in this way.

So if we stick to the standardized "configuration", we should document
it along the API and also use it when instantiating the cache:

$GLOBALS['typo3CacheFactory']->create('cache_extbase_reflection');

No further arguments. The cacheFactory will fetch the settings from the
configuration array (just like the "garbageCollect" task will also do).

What do you think?

Cheers,
Ernesto