![]() ![]() The purpose is the ability to accurately target multiple cache items that contain data about the same object, page, etc. The role of the tags is to identify cache items across multiple bins for proper invalidation. Cache tagsĪnother cool new feature of the Cache API in Drupal 8 are the cache tags (the fourth parameter in the setter method). ![]() These actions also happen only on the bin the CacheBackend is wrapping and completely remove the respective table records. Removing items altogether can be done using the delete(), deleteMultiple() or deleteAll() methods. However, we can also invalidate items manually using the invalidate(), invalidateMultiple() or invalidateAll() methods on the CacheBackend object. When this time lapses, the cache item becomes invalid but still exists in the bin and can be retrieved. They will be removed at the next garbage collection which can also be called using the garbageCollection() method on the CacheBackend object.Īs mentioned above, when storing a cache item we can specify an expiration time. Cache invalidation and removalĬache invalidation means that the respective items are no longer fresh and are unreliable in terms of what data they hold. This will set a permanent cache item tagged with 2 tags and store a serialised version of $my_object as the data. tags (an array of cache tags this item can be later identified by)Īs an example: Drupal :: cache ( ) -> set ( 'my_value', $my_object, CacheBackendInterface :: CACHE_PERMANENT, array ( 'my_first_tag', 'my_second_tag' ) ). ![]() It is best practice to use the Drupal\Core\Cache\CacheBackendInterface::CACHE_PERMANENT constant to represent this value) ![]() the expiration time (a timestamp in the future when this cache item will automatically become invalid or -1 which basically means this item never expires.the data (a PHP value such as a string, array or object that gets serialised automatically and stored in the table – should not be over 1MB in size).the cache ID (the string by which we can later reference the item).To store an item we use the set() method (instead of get() like before), a method that takes 2 mandatory parameters and 2 optional ones: Storing cache itemsĪlthough storing new items in the cache is just as easy as retrieving them, we have more options when doing so. Passing the boolean true as a second parameter will force it to return the data. The my_value parameter is the cache ID.Īn important thing to keep in mind is that using the get() method without a second parameter will not return the cache item if it has been invalidated (either programatically or through expiration). $cache will be a stdClass object containing some metadata about the cache item plus the actual data available under the $cache->data property. $cache = \Drupal :: cache ( ) -> get ( 'my_value' ) Once we know which bin we want to work with (for custom modules this will usually be the default bin), we can retrieve and store cache items. Here you can get a list of all core services including the ones related to cache.īut for the sake of brevity, we will use it statically here. You can do so by specifying as an argument to your service the relevant cache bin service (such as fault). If we are working inside classes, it is best practice to inject the service from the container. Where $render_cache will represent the render cache bin (which is new in Drupal 8 and is supposed to improve render performance across the board).Īs you can see, we are requesting the cache service statically using the \Drupal class. To request a particular bin we pass in the name in the constructor: $render_cache = \Drupal :: cache ( 'render' ) Where $cache will be an instance of the DatabaseBackend object that represents the default bin ( cache_default). When interacting with the cache, we always start by requesting a cache bin: $cache = \Drupal :: cache ( ) The new cache API (with the default DatabaseBackend storage) is stored in multiple bins which map to tables that start with the prefix cache_. ![]()
0 Comments
Leave a Reply. |