Cache_Store provides the public interface for working with the cache system. Internally it uses one or more engines to service requests.
It's possible to construct and use an instance of Cache_Store on its own, however, the preferred method for working with the cache is to call Support_Resources::cache() (see Support_Resources).
There are currently three supported options that are not engine-specific. They are:
The expiration_check option specifies a callback which, if provided, the get() method will use to check the validity of a cached data item before returning it. The callback is passed two parameters: a reference to the key value get() was called with, and a reference to the data value it is about to return. If the expiration check callback returns a boolean false value, the cached item is expired and will not be returned to get's caller.
The expiration check and data callback accepted by get() can be combined to more easily handle certain caching scenarios. As a simple example, let's say you're writing a blog application. To show off the caching functionality, let's imagine you've done some kind of fancy threading that takes a while to assemble, so you want to cache the result and only regenerate when you have to. You could choose to implement something like this:
Admittedly, the example is a bit contrived. It does show usage of the two callback features, but in reality, if your own application is in charge of handling updates to comments on a post, it would be better to simply expire the cached item whenever new comments come in. However, the expiration_check callback can be very handy for when items may expire due to events outside of the control of your application. For example, when a configuration file is changed or if database entries may be created by other applications.
Configuration
Any of the supported options (with the exception of expiration_check) may also be specified in the config file as a way to control the defaults for cache storage. Cache configuration options are named the same as the options that may be passed to Cache_Store, but they must be inside the cache section. That is to say, the following configuration options are supported:
Profiles may be created by placing the configuration options for that profile in cache/profiles/profile_name/options.... For example, you could create the following options:
Located in /cache/lib/Cache/Store.php (line 122)
Constructor
Remove all items from the cache.
This removes all items from a cache engine.
Options are:
Conditionally removes an item based on it being unchanged
Return the engine specified in the options.
The conversion from an engine name to an implementing class is "Cache_Engine_" . Support_Inflector::camelize($name).
Test for the existence of key in the cache.
Options are:
Remove key and its data from the cache.
Options are:
Return the value for key.
If a callback is provided, it is called if key does not exist, and the value the callback returns is set in the cache and returned. This is useful not only for conditionally production the cache value, but if the underlying cache engine supports locking, this will also prevent multiple simultaneous attempts (in different processes or threads) to produce the value for the same key.
Options are:
Tests if an item is considered valid (has not yet expired)
Returns a clean key value
Return a logger instance
Store a value for key.
Options are:
Return the correct set of options to use for a provided options argument
Documentation generated on Wed, 25 Apr 2012 09:46:45 -0700 by phpDocumentor 1.4.3