How Caching Works
Module developers can store a cache of their data into one of the tables reserved for caching within the Drupal database, or they can create a new table for cache storage. The next time this information is needed, it can be quickly retrieved with a single query and bypass expensive data manipulations.
The default table to which your module can write cached information is named cache. Using this table is the best option when storing only a couple rows of cached information. If you're caching information for every node, menu, or user, you'll want your module to have its own dedicated cache table to improve performance by minimizing the number of rows in Drupal's cache table. When defining a new cache table for your module to use, it must be structurally identical to the default cache table while having a different table name. It's a good idea to prepend cache_ to the table name for consistency. Let's take a look at the database structure of the cache table; see Table 15-1.
■Note When defining a new cache table for your module, it must be structurally identical to the default cache table.
|
Table 15-1. |
Cache Table Schema | ||
|
Field |
Type |
Null |
Index |
|
cid |
varchar(255) |
NO |
PRIMARY |
|
data |
longblob |
YES | |
|
expire |
int |
NO |
MULTIPLE |
|
created |
int |
NO | |
|
headers |
text |
YES |
The cid column stores the primary cache ID for quick retrieval. Examples of cache IDs used within the Drupal core are the URL of the page for page caching (e.g., http ://example. com/ ?q=taxonomy/term/1), a user ID and locale for caching user menus (e.g., 1:en), or even regular strings (e.g., the contents of the variables table are cached with the primary cache ID set to variables).
The data column stores the information you wish to cache. Complex data types such as arrays or objects need to be serialized using PHP's serialize() function to preserve their data structure within the database. This also means that you'll need to unserialize the data value using PHP's unserialize() function to rebuild the array or object when it's retrieved from the cache.
The expire column takes one of the three following values:
• CACHE_PERMANENT: Indicates that the item should not be removed until cache_clear_all() has been called with the cache ID of the permanent item to wipe.
• CACHE_TEMPORARY: Indicates that the item should be removed the next time cache_ clear_all() is called for a "general" wipe, with no minimum time enforcement imposed. Items marked CACHE_PERMANENT will not be removed from the cache.
• A Unix timestamp: Indicates that the item should be kept at least until the time provided, after which it will behave like an item marked CACHE_TEMPORARY and become eligible for deletion.
The created column is the date the cache entry was created and is not used in determining cache lifetime.
The headers column is for storing HTTP header responses when the cache data is an entire Drupal page request. Most of the time, you won't use the headers field, as you'll be caching data that doesn't rely on headers, such as parts of the page rather than the entire page itself. Bear in mind, though, that your custom cache table structure must still be identical to the default cache table, so keep the headers column around even if it isn't being used.
Average user rating: 5 stars out of 1 votes
Post a comment