Description

Currently the Zend_Cache_Backend_Interface does not allow for the possibility of having per-item lifetimes. In addition, due to the way directives are set, you cannot retrieve the current lifetime, change it, and reset it.

By adding in an additional optional variable on calls to save() on the backend, you can allow this feature and not break current usage.

I highly recommend this change, because in production enviroments it's often needed set individual lifetimes. With
memcache or APC as backend, there's nothing more to do, because APC/memcache function support lifetime/ttl options, if you
apply the patch by Lee.

When using the File backend, you also should improve the _clean method (Zend_Cache_Backend_File) in a way that
it cleans the cache records (files) in regard to the specified lifetime. You could do this by either storing the
lifetime in the file, or adding the lifetime to the filename.

I would suggest the latter option, because you wouldn't have to open each file for finding the desired lifetime.
Example filename could be cache_$id_$lifeTime.

Sorry, I have to cancel my last suggestion. Storing the lifetime in the cache file is a bad idea, because
the Cache wouldn't know the exact filename (so it would become difficult to open it fast enough). :-)

So there're two other options (if i'm right this time):
a) store lifetime in the file
b) store lifetimes of cache in extra file

Choosing a) would cause the clean process to last a bit longer (opening the files). The advantage
would be, that the load-method also could delete expired records.

Option b) would allow faster deletion by the the _clean method, but causes a little overhead
when creating the cache file.

I strongly agree with this. A global lifetime on its own is insufficient for the kinds of things I do, and creating multiple Zend_Cache objects seems superfluous.

To elaborate on Christian's comment, your two options could be:

Prepending each serialized cache file with the expiration UTS ending with some delimiter. This increases fetch time a small bit because of the string splitting, but probably more than compensates for it by eliminating the need to load a separate file (as the next option does).

Creating a separate file containing a serialized hash of filename => lifetime values. Whenever possible, I think the overhead should be shifted to when the cache is created, but this file would quickly become ridiculously large on large applications with dynamic caching. Besides the extra require_once, the reading of the file itself would become cumbersome. And if it's deleted somehow, it would invalidate the entire cache.

For those reasons, I'm in favor of embedding the lifetime in the cached file itself.

As far as usage, I would prefer the ability to do something like the following:

```

A global lifetime could still be set, but it would only be a default value.

Posted by Lee Saferite (lsaferite) on 2006-11-30T19:02:37.000+0000

Even though I forgot to make a patch file for or even mention it, this should of course apply to the frontend as well.

Posted by Fabien MARTY (fab) on 2007-02-08T15:34:11.000+0000

this feature is now in SVN version (you can use a specfic lifetime per cache (fourth argument of the save() method)