Cache Manager

Purpose and Scope

The CacheManager class serves as the central factory for creating and managing cache store instances in the hypervel/cache package. It implements the Factory pattern to provide a unified interface for accessing different cache drivers (Redis, Database, Swoole, File, etc.) while handling driver resolution, configuration management, store caching, and event dispatcher integration.

This document covers the internal workings of CacheManager as a factory. For information about using the cache system from application code, see the Repository Pattern (2.2). For details about individual store implementations, see Cache Stores (3). For framework integration and bootstrapping, see Framework Integration (5.1).

Sources: src/CacheManager.php1-335

---

Class Overview

The CacheManager implements the FactoryContract interface and acts as a service locator for cache repositories. It maintains an internal registry of resolved stores and supports both built-in drivers and custom driver registration.

Property	Type	Purpose
$stores	array	Registry of resolved cache store instances
$customCreators	array	Registered custom driver creator closures
$app	ContainerInterface	Hyperf DI container reference

The class uses the @mixin annotations to provide IDE support for proxying method calls to the default repository instance:

@mixin \Hypervel\Cache\Contracts\Repository
@mixin \Hypervel\Cache\Contracts\LockProvider
@mixin \Hypervel\Cache\TaggableStore

Sources: src/CacheManager.php25-43

---

Store Resolution and Caching

Resolution Flow

The CacheManager resolves cache stores lazily when requested, caching the resolved instances for reuse. The resolution process follows this flow:

Sources: src/CacheManager.php56-61 src/CacheManager.php172-191

Primary Access Methods

Method	Purpose	Behavior
store(?string $name)	Get a named store	Returns default if $name is null
driver(?string $driver)	Alias for store()	Identical to store() method
getStore(string $name)	Protected helper	Used internally for resolution

The store() method implements lazy caching using the null coalescing assignment operator:

Sources: src/CacheManager.php56-69 src/CacheManager.php162-165

Magic Method Proxying

The __call() magic method delegates all undefined method calls to the default driver's repository instance:

This allows code like $cacheManager->get('key') to transparently call $cacheManager->store()->get('key').

Sources: src/CacheManager.php48-51

---

Built-in Driver Creation Methods

The CacheManager includes factory methods for each built-in driver. The resolution logic checks for a method named create{Driver}Driver where {Driver} is the capitalized driver name from configuration.

Sources: src/CacheManager.php184-191

Array Driver

Creates an in-memory cache store with optional serialization:

Configuration Key	Type	Purpose
serialize	bool	Enable value serialization

Sources: src/CacheManager.php204-207

File Driver

Creates a filesystem-based cache store with configurable paths and permissions:

Configuration Key	Type	Purpose
path	string	Cache file directory
permission	int|null	File permission mode
lock_path	string|null	Lock file directory

Sources: src/CacheManager.php212-220

Null Driver

Creates a no-op cache store that always returns null:

This driver is useful for testing or disabling caching without code changes.

Sources: src/CacheManager.php225-228

Redis Driver

Creates a Redis-backed cache store with connection pooling:

Configuration Key	Type	Purpose
connection	string	Redis connection name
lock_connection	string	Redis connection for locks
prefix	string	Key prefix

Sources: src/CacheManager.php233-245

Swoole Driver

Creates a Swoole table-based cache store with memory management:

Configuration Key	Type	Purpose
table	string	Swoole table name
memory_limit_buffer	float	Memory buffer threshold
eviction_policy	string	Eviction policy (LRU/LFU/TTL)
eviction_proportion	float	Proportion to evict

Sources: src/CacheManager.php250-261

Stack Driver

Creates a multi-tier cache store by composing other stores:

The stack driver resolves each tier by calling getStore() to retrieve the underlying store, then wraps it in a StackStoreProxy for TTL enforcement.

Sources: src/CacheManager.php266-280

Database Driver

Creates a database-backed cache store with lock table support:

Configuration Key	Type	Purpose
connection	string	Database connection name
table	string	Cache table name
prefix	string	Key prefix
lock_table	string	Lock table name
lock_lottery	array	Lock cleanup lottery odds
lock_timeout	int	Lock expiration seconds

Sources: src/CacheManager.php285-300

---

Repository Creation and Event Integration

The repository() method creates a Repository instance that wraps a store and optionally attaches the event dispatcher:

The method uses Hyperf's tap() helper for fluent configuration:

Sources: src/CacheManager.php74-81 src/CacheManager.php305-314

Event Dispatcher Refresh

The refreshEventDispatcher() method re-attaches the event dispatcher to all resolved repositories:

This is useful when the event dispatcher instance changes at runtime.

Sources: src/CacheManager.php86-93

---

Custom Driver Registration

The extend() method allows registration of custom cache drivers at runtime:

Registration API

The closure is bound to the CacheManager instance, giving it access to protected methods and properties. The closure signature should be:

Sources: src/CacheManager.php142-147

Custom Driver Resolution

When resolving a store, the manager checks for custom creators before built-in drivers:

Sources: src/CacheManager.php180-188 src/CacheManager.php196-199

---

Configuration Management

Default Driver Resolution

The getDefaultDriver() and setDefaultDriver() methods manage the default cache driver:

Configuration Path	Default Value	Purpose
cache.default	'file'	Default driver name

Sources: src/CacheManager.php98-111

Store Configuration Retrieval

The getConfig() method retrieves store-specific configuration with special handling for the null driver:

The null driver doesn't require configuration, so a minimal config array is returned inline.

Sources: src/CacheManager.php327-334

Prefix Resolution

The getPrefix() method resolves the cache key prefix from store config or global config:

Configuration Path	Scope	Priority
cache.stores.{name}.prefix	Store-specific	High
cache.prefix	Global	Fallback

Sources: src/CacheManager.php319-322

---

Store Lifecycle Management

Store Forgetting

The forgetDriver() method removes resolved stores from the internal cache without disconnecting them:

This method accepts a string, array of strings, or null (defaults to default driver). It returns $this for method chaining.

Sources: src/CacheManager.php116-127

Store Purging

The purge() method is similar to forgetDriver() but only accepts a single store name:

The distinction between forgetDriver() and purge() is minimal in the current implementation, with purge() being simpler and not supporting arrays.

Sources: src/CacheManager.php132-137

Container Management

The setApplication() method allows runtime replacement of the DI container:

This is primarily used for testing or advanced use cases where the container needs to be swapped.

Sources: src/CacheManager.php152-157

---

Complete Driver Resolution Flow

The following diagram shows the complete flow from application request to resolved repository:

Sources: src/CacheManager.php56-61 src/CacheManager.php172-191 src/CacheManager.php74-81

---

Factory Pattern Implementation

The CacheManager implements a classic Factory pattern with several enhancements:

Pattern	Implementation	Benefit
Factory Method	create*Driver() methods	Type-specific instantiation logic
Registry	$stores array	Singleton-like store caching
Strategy	$customCreators closures	Runtime driver extensibility
Lazy Loading	??= operator	On-demand resolution

The combination of these patterns provides a flexible, extensible cache system that balances performance (via caching) with flexibility (via custom drivers).

Sources: src/CacheManager.php25-335