Tdbm Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on the persistence layer. TDBM is a schema-first ORM: it generates beans and DAOs directly from an existing SQL schema. This is a genuine alternative to hand-rolling a data-access layer for teams whose database is the source of truth (DBA-owned schemas, legacy or reporting-heavy databases) rather than the application code.
• Framework upgrade roadmap. v6.1.0 adds Symfony 7 support. For any product on Symfony 5.4/6.x, this is the signal that the persistence dependency will not block a Symfony 7 upgrade track — a roadmap unblocking item, not a feature.
• Use cases where it fits. Internal and back-office tooling, CRUD-heavy admin surfaces, and modernization of legacy schemas where tables, foreign keys, and views already exist and rewriting them as code-first entities would be pure cost.
• Use cases where it does not fit. Greenfield products where the domain model should drive the schema, or codebases that need heavy ecosystem support. Note the obvious scoping caveat: this is a Symfony bundle, not a Laravel package. If the product is Laravel-first, the decision is effectively "use Eloquent" and this evaluation is moot.

When to Consider This Package

Adopt when:

• The application is Symfony-based and the team works schema-first, with an existing database whose constraints and relationships are already well defined.
• You want strongly typed generated model and DAO classes with good IDE support and less runtime "magic" than a full data-mapper ORM.
• You are planning a Symfony 7 upgrade and need the persistence layer to be compatible (v6.1.0 satisfies this).

Look elsewhere when:

• The stack is Laravel — Eloquent is the native answer, and introducing a Symfony bundle is not a serious option.
• You need a large community, frequent releases, and broad third-party integration (Doctrine is the default for good reason).
• The team cannot absorb a generated-code workflow (regeneration on schema change, generated files in or out of version control).
• Domain-driven, code-first modeling is a product requirement.

Due diligence before committing: v6.1.0 is the first release since v6.0.0 and the change is a single compatibility contribution from a first-time contributor. Release cadence is slow and the maintainer base is thin. Verify the PHP/Symfony support matrix, the security-response process, and whether your team can patch the package themselves if needed.

How to Pitch It (Stakeholders)

For executives: This is a low-cost persistence layer for schema-first Symfony applications. The v6.1.0 release is small in scope but strategically useful: Symfony 7 support keeps the dependency aligned with our framework upgrade path, so it does not become the reason we delay a platform migration. The risk to weigh is vendor/community size, not capability — the package is narrow and replaceable, provided we avoid deep coupling.

For engineering: Generated beans and DAOs give type safety and IDE navigation straight from existing SQL, with no annotation layer to maintain and a much smaller surface than Doctrine. v6.1.0 is a compatibility bump only — no breaking changes, no deprecations, no migration work. The trade-offs are real: slow release cadence, one release since v6.0.0, and a small contributor base. Recommendation is to adopt with a boundary: keep the generated layer behind our own repository interfaces so a swap to Doctrine remains a contained project rather than a rewrite.