- What does cache/psr-6-doctrine-bridge actually do?
- It adapts any PSR-6 cache pool implementing Psr\Cache\CacheItemPoolInterface to Doctrine's legacy Doctrine\Common\Cache\Cache interface. You can call contains, fetch, save, and delete on the bridge, and retrieve the original pool with getCachePool. It only matters when a consumer is hardcoded against the legacy Doctrine cache interface.
- How do I install cache/psr-6-doctrine-bridge in a Laravel application?
- Install it with Composer using the version that matches your stack, such as composer require cache/psr-6-doctrine-bridge:^4.0. Then create a real PSR-6 pool and wrap it with new DoctrineCacheBridge($pool). Wire that bridge into the legacy Doctrine metadata, query, or result cache driver that needs it.
- Can I use Laravel's Cache facade or Redis store as the PSR-6 pool?
- Not directly. Laravel's cache repositories are PSR-16, not PSR-6, so there is no built-in Cache::store('redis')->getPsr6Adapter() path. You must supply a separate PSR-6 pool such as symfony/cache RedisAdapter or cache/adapter, which adds a second cache abstraction to the stack.
- Which Laravel versions does this package support?
- The package is framework-agnostic and does not target Laravel versions directly; support depends on Composer resolving its doctrine/cache and psr/cache constraints against your Laravel, Symfony, and Doctrine versions. Run composer require or composer why-not before planning adoption. If resolution forces a downgrade of psr/cache or doctrine/cache, stop the evaluation.
- Do I need this bridge with Doctrine ORM 2.11+ or 3.x?
- Usually no. Doctrine ORM 2.11+ and 3.x can consume PSR-6 pools natively, so injecting your pool directly into Doctrine's cache drivers is the preferred outcome. The bridge is only for legacy consumers that still type-hint or hardcode Doctrine\Common\Cache\Cache.
- How does the bridge handle Doctrine cache keys that contain backslashes, colons, or at signs?
- It keeps legacy normalized keys when the target pool accepts them. If the pool rejects a key, the bridge retries with a 64-character SHA-256 key. Confirm this behavior against your pool and serialization changes before depending on it across releases.
- What happens on deleteAll or Doctrine cache:clear with a shared Redis pool?
- The bridge likely maps deleteAll to the pool's clear method, which can wipe the entire shared pool including non-Doctrine entries. That is a critical production risk if the pool is shared with other applications or cache consumers. Use a dedicated pool or keyspace and test cache:clear behavior before rollout.
- Does setNamespace, getStats, or TTL handling work correctly?
- Namespace support is likely a no-op, so two apps in one Redis database can silently collide. getStats and getNamespace may be unsupported and throw or return empty. TTL semantics also differ between Doctrine's save($key, $value, 0) and PSR-6 item defaults, so test expiration behavior.
- Is this package safe to use in production?
- It is a small commodity shim with limited adoption, so treat it as legacy glue rather than a strategic dependency. The main risks are key charset mismatch, deleteAll clearing a shared pool, inert namespaces, and TTL or stats semantics. Gate adoption on Composer resolution and a dedicated pool, or internalize the roughly 200 lines.
- What are alternatives to cache/psr-6-doctrine-bridge?
- The best alternative is to upgrade the consumer to accept a PSR-6 pool directly, especially with Doctrine ORM 2.11+ or 3.x. If a legacy Doctrine\Common\Cache\Cache consumer cannot be changed, fork or internalize the bridge into your own namespace. You can also avoid Laravel's PSR-16 stores and provide a dedicated PSR-6 pool.