Trigger Mapping Laravel Package

Technical Evaluation

Framing correction up front: despite the "Laravel/PHP package" brief, talleu/trigger-mapping is a Symfony bundle built around Doctrine. Every integration estimate below assumes that mismatch is the dominant technical fact, not a footnote.

Architecture fit

• Provides an attribute/annotation-driven DSL for declaring SQL triggers as PHP classes, plus console tooling to push (and presumably diff/drop) those definitions into the database. The value proposition is "triggers as versioned code" instead of hand-written DDL that lives in nobody's repo.
• Fits cleanly only in a Symfony + Doctrine DBAL/ORM application. Laravel's Eloquent, service providers, and Artisan console are a different extension model: a bundle registers via DependencyInjection/*Extension and Bundle classes that Laravel never loads.
• Conceptually it is infrastructure-as-code for a schema object Doctrine itself does not model. That is genuinely useful, but it means the package sits beside the migration pipeline rather than inside it, which is where most of the risk concentrates.

Integration feasibility

• Low friction on a Symfony 6/7 + Doctrine DBAL stack: composer install, register the bundle, add attributes, run the sync command.
• Moderate-to-high friction on Laravel: you would need a service provider, an Artisan command wrapper, and a re-validation of the DBAL-only code paths. Realistically this is a fork, not an install.
• Trigger DDL is dialect-specific (MySQL CREATE TRIGGER ... FOR EACH ROW, PostgreSQL trigger functions, SQLite's limited support, SQL Server's different syntax entirely). Supported platforms are the first thing to verify, not the last.

Technical risk

• Dual source of truth. Doctrine's schema tool does not know about triggers. A doctrine:schema:update --force or a naive migration can leave triggers orphaned or duplicated. Unless the package ships a diff/idempotency layer, you get drift.
• Non-idempotent DDL. Re-running sync against an existing trigger must drop-then-create or detect equality; if it just issues CREATE TRIGGER, deploys fail on second run.
• Rollback story. Triggers created outside migrations are invisible to doctrine:migrations:rollback. Disaster recovery becomes "re-run the sync command against the restored DB," which must be documented and rehearsed.
• Version skew. DBAL 4 removed/relocated several Platform introspection methods; Symfony 7 tightened service definitions. A 93-star, single-maintainer bundle is unlikely to have a wide CI matrix.
• Signal quality. 0 dependents and ~93 stars means essentially no production testimony. The package is unvetted; treat it as a promising internal-library candidate rather than a dependency.

Key questions

1. Which database engines and versions are actually supported, and is there a CI matrix proving it?
2. Does it integrate with Doctrine Migrations, or does it run as an out-of-band command? Is there a --dry-run/diff mode usable in CI to detect drift?
3. Is sync idempotent, and does it support drop/rollback for triggers whose mapped class was deleted?
4. What DB privileges does it require (TRIGGER, SUPER on some MySQL configurations, ownership on Postgres)?
5. What is the maintainer's cadence and bus factor? Is the core usable as a plain library without the Symfony bundle layer?
6. Has anyone written a Laravel port, or would we own that bridge?

Integration Approach

Stack fit

• Symfony + Doctrine + MySQL/Postgres: native fit, adopt with a spike.
• Laravel: treat as evaluate-only. Reuse the DSL/generator classes if they are framework-agnostic; do not attempt to install the bundle. Budget a fork if the concept proves out.
• Any team relying on doctrine:schema:update in production should stop and fix that first — this package assumes migrations are the only schema authority.

Migration path

1. Inventory existing triggers directly from the database (information_schema.TRIGGERS on MySQL, pg_trigger on Postgres). Most teams are surprised by what is already there.
2. Codify one low-risk trigger (e.g., an audit/updated_at trigger) into a mapped class in a throwaway branch, run sync against a scratch schema, and diff the resulting DDL against the existing definition.
3. Move to managed mode behind a feature flag with a CI drift check that fails the build if live triggers diverge from the mapped classes.
4. Expand trigger-by-trigger; never bulk-import in one step.

Compatibility Build an explicit matrix and pin it: PHP minor version × Symfony LTS × Doctrine DBAL major × DB engine and version × package tag. Re-verify on every DBAL major bump, since that is where the introspection breakage lives. Also confirm the bundle's console command name and whether it collides with existing Doctrine commands.

Sequencing

• Week 1: read the source, confirm platform support and idempotency behavior. Cheap, and it decides everything else.
• Week 1–2: scratch-schema PoC plus a written rollback runbook.
• Week 2–3: CI drift check and DBA review of the generated DDL.
• Week 3+: adopt for one non-critical trigger; hold there for a full release cycle before expanding.
• Defer any Laravel work until the Symfony path proves valuable — otherwise you pay the porting cost twice.

Operational Impact

Maintenance

• Single maintainer, MIT, ~93 stars. Assume you may need to fork. Budget a named code owner and 1–2 days per quarter to keep the fork current.
• Pin to an exact tag; avoid ^ ranges on a package this small.
• The generated SQL is the real artifact. Store it in the repo (or in migrations) so a fork or removal is a mechanical change, not an archaeology project.

Support

• No commercial backing; GitHub issues only. Internal documentation and a runbook are non-optional.
• Escalation path is "read the source" — which is fine at this size, but should be stated explicitly so nobody expects vendor SLAs.

Scaling

• Runtime cost is database-side: triggers execute inside the writing transaction, so every INSERT/UPDATE on a mapped table pays the cost. Row-by-row trigger logic is a classic write-throughput trap; validate under realistic load before attaching triggers to hot tables.
• Deploy-time cost is the real constraint: creating a trigger takes a brief metadata lock. On large, high-traffic tables this must go through the standard online-DDL/lock-avoidance process, not a naive sync at deploy time.
• Replication and binlog/CDC consumers will see trigger side effects; anything downstream that assumes "one row change = one event" may double-count.

Failure modes

• Silent drift: schema:update drops or ignores triggers; app logic quietly stops firing. Detect via the CI drift check.
• Duplicate triggers on redeploy if sync is not idempotent — causes double-written audit rows or double-applied derivations.
• Orphaned triggers when a mapped class is deleted without a corresponding drop.
• Hidden business logic: logic that lives in the database is invisible to PHP debuggers, static analysis, and most tracing tools. Require a COMMENT on each trigger pointing at the owning class.
• Privilege gaps in managed database services (RDS, Cloud SQL) where the app user may be denied TRIGGER.
• Backup/restore asymmetry: restored snapshots carry triggers the mapping layer did not create, so post-restore sync may conflict.

Ramp-up

• For a Symfony developer: half a day to read the DSL, one to two days to be productive including the sync workflow.
• The real ramp-up is organizational, not individual: DBAs and platform engineers must accept a new schema-change path, and that review gate is what keeps the tool from becoming an ungoverned side door into production.
• For a Laravel team, multiply by the cost of building and owning the bridge — likely weeks, which the 93-star signal does not justify without a specific, painful trigger-management problem to solve.