- How do I install cache/prefixed-cache in a Laravel app?
- Run composer require cache/prefixed-cache:^2.0. There is no service provider or config file; you instantiate PrefixedCachePool::create($pool, 'billing.') around an existing PSR-6 pool, or PrefixedSimpleCache for PSR-16. In Laravel this means wiring the decorator yourself rather than expecting it to register through config/cache.php.
- Does cache/prefixed-cache work with Laravel's Cache facade or config/cache.php?
- No. Illuminate\Contracts\Cache\Repository is not a Psr\Cache\CacheItemPoolInterface, and CacheManager does not hand out PSR-6 pools, so the decorator cannot drop into config/cache.php. You only benefit if your process already holds a PSR-6 pool, such as a php-cache adapter, a symfony/cache PSR-6 adapter, or a vendor SDK that type-hints the PSR-6 interface. Reaching it from Cache::store() requires a custom store driver or adapter that you own and maintain.
- Should I use cache/prefixed-cache or Laravel's native cache prefix?
- For a normal Laravel app, the per-store prefix in config/cache.php plus a small tenant-aware key builder is simpler and adds no dependency. cache/prefixed-cache only pays off when you already have PSR-6 pools in-process and want namespacing at the pool level. Keep any composite prefix short, because PSR-6 only guarantees 64-character keys and long env_tenant_feature_version_ prefixes eat into that budget.
- What is the difference between PrefixedCachePool and NamespacedCachePool?
- PrefixedCachePool does not isolate clearing: clear() on the decorator clears the entire underlying pool, including keys written by other code. Use the separate namespaced cache package when you need to invalidate only your own keys. On a shared Redis or Memcached backend, assume full-pool clear() is unsafe and avoid cache:clear against that store.
- How does PrefixedCachePool::create() handle tags?
- PrefixedCachePool::create() returns a taggable decorator when the wrapped pool supports native tags, and tag invalidation is delegated to that pool. The public constructor always returns the basic PrefixedCachePool type, so use create() when you need setTags() on cache items. If the underlying pool has no tag support, you simply get the basic decorator.
- Can I use cache/prefixed-cache with PSR-16 simple caches?
- Use PrefixedSimpleCache to decorate a PSR-16 implementation such as a simple array or file cache. That still requires an actual PSR-16 object, so you may need an adapter around Laravel's repository. It is most useful for vendor libraries that accept a Psr\SimpleCache\CacheInterface.
- Which characters are safe in prefixed cache keys?
- PSR-6 reserves { } ( ) / \ @ : in keys, so examples like tenant_1:user_123 or acme:api:v1 can be rejected at runtime by strict pools such as Symfony adapters. Standardise on underscores or dots as separators and add a unit test that builds keys against your real pool before rollout. This is the single most likely production surprise with this package.
- How are prefixes encoded in version 2 of cache/prefixed-cache?
- Version 2 encodes prefixes before joining them to public keys using a reversible _xHH_ format. ASCII letters, digits, underscore and dot are left unchanged; every other byte, including each byte of non-ASCII text, is encoded, and a literal lowercase _x is encoded so it cannot be mistaken for an encoded byte. If you upgrade to or roll back from version 2 with a prefix containing other bytes, clear the affected caches first.
- What happens when I call clear() on a prefixed cache?
- clear() delegates to the full underlying pool, so on a shared backend it can wipe keys belonging to other apps or tenants. The decorator cannot reliably clear only its own prefixed keys. Prefer per-key TTLs and version-stamped prefixes for invalidation instead of relying on clear().
- Is cache/prefixed-cache actively maintained and safe for production?
- The repository is a read-only split of the php-cache monorepo, with issues and pull requests handled on the main repository, and it has very few stars and dependents. Treat it as vendorable MIT source rather than a heavily supported dependency, and confirm the actual latest release on Packagist because the metadata and source dates disagree. The decorator itself is small, so building or vendoring an equivalent is a reasonable alternative.