- How do I install cache/namespaced-cache in Laravel?
- Install it with composer require cache/namespaced-cache:^2.0, then wrap a PSR-6 CacheItemPoolInterface instance in NamespacedCachePool. It is not a Laravel package, so there is no service provider, facade, or config file to publish. You will need to bind the wrapped pool and namespace manually in a service provider or factory.
- Does this package integrate with Laravel's Cache facade?
- No. Laravel's Cache facade and Repository contract are not PSR-6, so the decorator cannot wrap Illuminate cache stores directly. You first need a PSR-6 adapter over the Laravel store, then wrap that adapter with NamespacedCachePool. That adapter is application code, not part of this package.
- How does clear() avoid flushing the entire shared pool?
- For ordinary PSR-6 pools it uses generation keys: bumping the namespace generation makes old entries unreachable, and the backend evicts them later. Hierarchical pools use their native hierarchy for namespace invalidation. This gives namespace-scoped clear() semantics without flushing unrelated namespaces, but old values may remain stored until eviction.
- What is the difference between NamespacedCachePool::create() and new NamespacedCachePool()?
- The public constructor always returns the basic NamespacedCachePool type. The static create() method returns a taggable decorator when the wrapped pool supports native tags. Use create() if you need setTags() and namespace-scoped tag indexes.
- Why does my namespaced cache return misses after deployment?
- A typo in the namespace string silently produces a cold namespace rather than an error. Generation metadata can also be evicted or lost, causing the decorator to store a new generation and miss older values. Check the exact namespace components and confirm metadata keys persist in the backend.
- How do I use cache tags with NamespacedCachePool?
- Call NamespacedCachePool::create() on a pool that supports native tags. The returned decorator preserves setTags() on cache items, scopes tag indexes to the namespace, and keeps getPreviousTags() returning public tag names. The plain constructor does not provide the taggable variant.
- Is cache/namespaced-cache compatible with Laravel 10 and 11?
- The package has no Laravel version coupling because it only targets PSR-6. Compatibility depends on the psr/cache version required by your Laravel app and other dependencies. Verify psr/cache ^2.0 or ^3.0 support before adopting version 2, especially alongside Symfony 6 or 7 libraries.
- How does hierarchical key deletion with the | prefix work?
- Keys beginning with | retain hierarchical deletion on every wrapped pool. Deleting |parent invalidates that key and its descendants without affecting siblings or ordinary keys. Deleting the root | invalidates every hierarchical key in the namespace while ordinary keys remain available.
- What production risks should I check before using this in multi-tenant Redis?
- Confirm whether clear() is truly namespace-scoped; a global flush in a multi-tenant Redis pool is a data-loss incident. Watch for namespace-wide operations that scan the underlying pool with KEYS or SCAN and can block at scale. Test decorator ordering with tags, because wrong ordering silently breaks invalidation. Also record the namespace-to-backend-key mapping so cache debugging and hit-rate dashboards still work.
- Is cache/namespaced-cache actively maintained, and what alternatives should I consider?
- Treat it as a vendored utility: the repo is a read-only split with redirected issues and PRs, low stars, and no downstream dependents. Alternatives include Laravel's per-store prefix, Cache::tags(), a small tenantKey() helper, or sibling php-cache decorators such as hierarchical-cache. Use namespaced-cache only when you genuinely need to share a PSR-6 pool across Laravel and non-Laravel consumers.