Doctrine Adapter Laravel Package

Product Decisions This Supports

• Build vs. buy for a legacy cache bridge. cache/doctrine-adapter is a thin, MIT-licensed, ~single-class adapter (DoctrineCachePool) that makes a Doctrine\Common\Cache\* provider consumable through PSR-6 (Psr\Cache\CacheItemPoolInterface). The only decision it genuinely accelerates is "do we build a Doctrine→PSR-6 shim ourselves, or vendor one?" If you already have Doctrine 1.x cache providers wired into ORM/DBAL metadata or query caches and a modern PSR-6 consumer (Laravel's Illuminate\Cache\Repository, PSR-6 middleware, a third-party library that type-hints the PSR-6 interface), this package removes a day or two of glue code and replaces it with a maintained, spec-compliant shim. That is the whole value proposition — and it is a small one.
• A PSR-6 standardization stepping stone, not a destination. The adapter's real product role is interoperability plumbing: one interface (CacheItemPoolInterface) in front of an existing Doctrine driver so that cache consumers stop caring which backend is underneath. This supports a roadmap story of "single cache contract across services," but it does not support a story of "modernize our cache layer" — the adapter sits on top of the very layer that needs modernizing. Treat it as scaffolding for a migration, with an explicit expiry date.
• Migration sequencing decisions. It enables low-risk, incremental migration: keep the Doctrine driver your ORM already depends on, expose it via PSR-6 to new code, then swap the underlying pool for a native PSR-6/PSR-16 implementation once the consumers are standardized. This is a legitimate "strangler fig" pattern for caching and is the strongest argument for adoption.
• Tag/hierarchy feature claims need product verification. The README defers tagging and hierarchy to shared php-cache documentation; that capability comes from the php-cache ecosystem layer, not from this bridge. Any roadmap item resting on "granular tag invalidation via Doctrine" should be treated as unvalidated until proven in a spike — Doctrine's own cache API has no tagging contract, and Laravel's Cache::tags() semantics are not guaranteed to map cleanly.
• Use cases where it is defensible:
  • Laravel (or any PSR-6 host) application with a substantial existing Doctrine ORM/DBAL footprint where the Doctrine cache providers are already a de-facto shared cache.
  • A short-lived integration project where a third-party library requires PSR-6 and the only available backend is a Doctrine driver (e.g., MemcachedCache, RedisCache, ApcuCache).
  • Sunset/migration work: bridging during a transition so downstream teams aren't blocked on the backend swap.
• Decisions this package should not anchor. Do not let it drive a caching architecture decision, a multi-year platform commitment, or a "tagging strategy" bet. It is glue.

When to Consider This Package

• Adopt only when all of these hold:
  1. You have a hard dependency on doctrine/cache 1.x (ORM/DBAL metadata, query, or result caches) that you cannot remove within this planning horizon.
  2. You have a PSR-6 consumer that cannot be pointed at a native PSR-6 pool — i.e., the backend is only reachable through a Doctrine\Common\Cache\Cache instance.
  3. The integration is scoped and reversible — ideally a single service or module, behind a config flag, with a documented exit path.
  4. You have accepted ownership of the code: the upstream repo is [READ-ONLY], has 13 stars and zero dependents, and its release metadata is inconsistent (release notes are pointer stubs pointing to an external changelog; the recorded last-release date conflicts with the package's apparent 2022-era activity). Plan for the realistic scenario that you fork it if you need a fix.
• Look elsewhere — usually — when:
  • You're on doctrine/cache 2.x or later. Doctrine moved away from the Doctrine\Common\Cache\Cache interface toward PSR-6/PSR-16; this adapter targets the legacy interface. Verify the exact supported constraint before scoping anything; a mismatch here invalidates the entire evaluation.
  • You are on stock Laravel with a native driver. redis, memcached, database, dynamodb are first-class, tested by the framework, and support Cache::tags() natively. Wrapping Doctrine to reach Memcached/Redis through a read-only adapter with zero dependents is a strict downgrade in support surface for zero functional gain.
  • You need tag-based invalidation as a product requirement. Native Laravel drivers implement tags; this bridge does not guarantee them. Do not commit to a feature on top of an unverified capability.
  • You need PSR-16 (simple cache). Wrong package — look at a PSR-16 implementation or a maintained polyglot cache library.
  • You need a maintained, security-responsive dependency. symfony/cache (which itself adapts Doctrine caches and is actively maintained) or cache/adapter-bundle-style ecosystem alternatives are safer bets. Prefer a package with real dependents and a release cadence over one with 13 stars and a read-only flag.
• Mandatory diligence before any commitment: pin an integration spike that (a) confirms the doctrine/cache constraint against your installed tree, (b) validates PSR-6 key-character constraints ({}()/\@: are rejected — Laravel-generated keys like model:123 contain : and must be sanitized), (c) proves or disproves tag behavior, and (d) benchmarks against the native driver. If the spike shows no behavioral gap versus native drivers, the correct decision is to not adopt.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated a small open-source adapter that lets our existing Doctrine cache drivers speak the standard PSR-6 caching interface. It is a bridge, not a platform: it costs nothing to license, removes a little bespoke glue code in a narrow legacy scenario, and carries a support risk because the project is read-only with negligible adoption. Our recommendation is to treat it as migration scaffolding, not an architectural commitment — approve it only inside a time-boxed integration where we already depend on Doctrine's legacy cache, and only with a documented plan to remove it in favor of a natively supported cache driver. It should not appear on a roadmap as a capability.

To engineering (briefing bullets):

• What it is: DoctrineCachePool — wraps any Doctrine\Common\Cache\Cache provider and exposes it as a PSR-6 CacheItemPoolInterface. One class, MIT, part of the php-cache org.
• What it is not: a new cache backend, a tag-invalidation engine, or a modernization path. Tagging/hierarchy support lives in the surrounding php-cache ecosystem, not here, and is unverified for our use cases.
• Known sharp edges: PSR-6 forbids {}()/\@: in keys, so our existing key generation (Eloquent-style model:123) needs sanitization; the adapter adds an indirection layer over the driver, so benchmark before assuming parity; and the repo is read-only with 13 stars and 0 dependents, so assume we own any fixes.
• Decision gate: we adopt only if a spike proves (i) a genuine capability we cannot get from a native Laravel driver, and (ii) an exit path. Otherwise the correct call — and the default — is a native driver or symfony/cache.