Issues

ZF-4585: Allow Zend_Config to cache its data

Description

As performance is a critical point, I think Zend_Config should be given some kind of setCache(Zend_Cache_Core $cache) method to cache its data (or to cache itself, why not ?). This would prevent opening and parsing the backend (xml or ini) file each time we create the Zend_Config instance.

Comments

why not but it's probably a Zend_Config work, isn't it ?

so I changed the component to Zend_Config

Oups, sorry about that, I thought I chose Zend_Config ....

Generally the logic around Zend_Config object is not just as simple as creating one. There's also merging etc. Also, you may not want to cache the config loading at all times.

I would have thought that it's just as easy to cache outside the config object?

Maybe something like:


$cacheName = 'config';
$configArray = $cache->load($cacheName);
if ($configArray === false || $configSection == 'dev') {
    $config = new Zend_Config_Ini(...);
    // do merging or whatver else you need to do

    $query_cache->save(config->toArray(), $cacheName);
} else {
    $config = new Zend_Config($configArray());
}

Having said that, if you have a concept of what setCache() would do and how it would be used I'm interested in looking at what we can do.

Rob...

Yes Rob you are right.

I have a solution, but it still stats the FS even if it prevents from loading the data back from the file. So it's no good as we cant prevent the stat() call on the FS (probably often the highest 'cost'), can we ?

Hey Rob, I found a way to make it :-)

Anyway, the cache should be memory-backend based to prevent any stat call. It's a mess to cache data from a file into a file-based cache....

What do you suggest ? If I let the user specify its own Zend_Cache_Core instance, it might use a file-based backend : no good solution

I could force him to set a memory-based backend instance instead.

Patches attached

Patches.

Not commented/tested yet, just as a reflection base.

To be honest, I'm not yet convinced.

My current issues: 1. It unnecessarily couples Zend_Config to Zend_Cache which makes it harder to extract Zend_Config for using in a non ZF app.

  1. It's common to manipulate the config object before you would want to cache it. It's not clear how caching within the object would handle this.

  2. It's not clear how it would work in practice. Most components use a setCache() function, but Zend_Config loads directly in the constructor. Ideally, if we really wanted integrated caching, we'd refactor Zend_Config so that we could call setCache() before calling some sort of load() method.

With your patches, we have to use a static function to set the cache which seems counter-intuitive to me and I wonder how you would handle having different caching strategies for different configs.

I still think that it's easier to do it outside of the Zend_Config as cited above.

Postponing until we start thinking about ZF2.0, as to add caching properly to Zend_Config requires API changes that will probably break B/C.

Closing this issue as it's now noted on the Zend_Config 2.0 wiki page (http://framework.zend.com/wiki/display/…) .

Will reopen/create a new issue if we actually decide to go ahead with this one.