Ting Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on the persistence layer. Ting is a third-party, open-source (maintained by a single author, Xavier Leune) persistence layer that replaces Doctrine ORM for Symfony apps. Choosing it is a "buy" decision with a real exit cost — the 4.0 upgrade shows every major version carries breaking changes and a migration guide. That trade-off belongs in an ADR, not a sprint ticket.
• Roadmap gating for framework upgrades. 4.0 requires PHP 8.2+ (8.4 for Symfony 8) and Symfony 7.4 or 8. If the platform roadmap includes Symfony 8 or long-lived worker runtimes (FrankenPHP, RoadRunner), this release is the enabling dependency; if the team is pinned to Symfony 6.x, it is blocked.
• Worker-mode readiness as a product requirement. Repositories, connection pools, unit of work, loggers and collectors are now reset between requests. This is the concrete evidence needed to green-light a FrankenPHP/RoadRunner migration for performance or cost reasons — the persistence layer is no longer the blocker.
• Developer-velocity investment. Less boilerplate per entity (default_connection / default_database, attribute mapping, backend enums stored as their value, type-aware change tracking) translates to onboarding time and ticket throughput. Justifies a spike or pilot budget.
• Observability and debuggability bets. Route-level entity resolution and every query visible in the profiler supports the "reduce mean time to diagnose" objective and reduces reliance on bespoke logging.
• Migration sequencing. The rename master/slaves → primary/replicas, cache_provider now being a Symfony cache pool id, and 3.x JSON-encoded enum values needing conversion are all scoped work items. Their existence in the release notes is what lets you size the upgrade before committing to a release date.
• Risk tracking. The breaking-change list plus the ccmbenchmark/ting_bundle → xavierleune/ting_bundle namespace switch make this a supply-chain and maintenance-risk item for the architecture review, not just a dependency bump.

When to Consider This Package

Adopt when:

• The application is Symfony 7.4 or 8 on PHP 8.2+. This is a Symfony bundle; it is not a Laravel package, and Laravel teams should stop here — Eloquent or Doctrine via a bridge are the realistic options.
• The team wants an attribute-mapped, low-ceremony persistence layer and is willing to trade Doctrine's ecosystem breadth (DBAL tooling, migrations bundle, third-party integrations, hiring pool) for less code and a faster core.
• Worker-mode deployment (FrankenPHP, RoadRunner) is on the roadmap; request-scoped reset of repositories is now handled.
• Profiler-level query visibility and route-to-entity resolution materially shorten debugging cycles for the team.
• The team is already on Ting 3.x and is doing a planned major-version hop with capacity to absorb the upgrade guide and enum storage conversion.

Look elsewhere when:

• Laravel is the framework — this package does not apply.
• The codebase depends on the Doctrine ecosystem (Doctrine Migrations, DBAL types, bundles that type-hint EntityManager). Ting is a replacement, not a drop-in.
• You require vendor maturity and support SLAs: single-maintainer, pre-5.0 software, breaking changes on every major, and a test suite that just moved from atoum to PHPUnit signals a still-evolving project.
• The team is on Symfony ≤ 7.3 or PHP < 8.2, or cannot schedule the rename/migration work in 4.0.
• Data integrity constraints around enum storage are strict and the 3.x JSON-encoded values cannot be safely converted — staying on the legacy enum_serializer: symfony_serializer is a stopgap, not a strategy.
• You need long-term LTS-style stability with predictable deprecation windows; prefer Doctrine ORM.

How to Pitch It (Stakeholders)

To executives: Ting 4.0 is a maintenance and capability release for our Symfony persistence layer. It unlocks Symfony 8 and PHP 8.4, removes the dependency on the abandoned doctrine/cache, and makes the stack safe for high-throughput worker runtimes — which is where our hosting cost and latency gains are. The cost is a bounded, documented migration: renamed connection keys, a cache-provider swap, and a one-time enum value conversion. Recommendation: approve the upgrade as a scoped piece of work in the Symfony 8 platform track, not as an open-ended refactor. Key risk to note: single-maintainer dependency; we should record it in the risk register with an exit plan.

To engineering: This is a breaking major — read UPGRADE-4.0.md and Ting's own upgrade guide first. Concrete work items: master/slaves → primary/replicas; cache_provider becomes a Symfony cache pool id; UniqueEntity takes named arguments only; enum values written by 3.x are JSON-encoded and must be converted (or pinned with enum_serializer: symfony_serializer); if we ever came from the ccmbenchmark namespace, check config/bundles.php under Flex. Upside: container build now fails loudly on union-typed/untyped #[Column] or incomplete #[Table] mappings — schema mistakes surface at build, not in production. Repositories are autowirable services and reset per request, and the profiler shows every query. Services are declared in PHP with no deprecations on 7.4 or 8. Ask: one spike to run the upgrade on a branch and report the diff size before we commit a date.

One-line version: Ting 4.0 modernises our Symfony persistence layer and clears the path to Symfony 8 and worker mode, at the price of a documented, finite migration on a single-maintainer dependency.