Download the PHP package talleu/trigger-mapping without Composer

On this page you can find all versions of the php package talleu/trigger-mapping. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of talleu/trigger-mapping

Informations about the package trigger-mapping

🧩 Trigger Mapping Bundle

Packagist Version PHP Version CI

Map, validate, version-control and deploy your database SQL triggers declaratively from your Doctrine entities — with PHP attributes.

Your trigger schema becomes declarative, reviewable in PRs, version-controlled alongside your code, and validated by your CI. No more SQL drift between branches, environments and teammates.

Table of contents

Why this bundle?

Database triggers are powerful (cascading audit logs, denormalized counters, soft deletes, history tables, hierarchical constraints…) but they are invisible from your application code. They live somewhere in the DB, often only known to the dev who wrote them, and slowly drift between environments.

This bundle solves that:

📋 Compatibility

Component Supported
PHP 8.2 · 8.3 · 8.4
Symfony 6.4 LTS · 7.x · 8.0
Doctrine ORM ^2.16 · ^3.0 (ready for ^4.0)
Doctrine DBAL ^3.0 · ^4.0
Doctrine Migrations Bundle ^3.2 · ^4.0 — optional, only required if migrations: true
PostgreSQL ≥ 12 (full feature parity from 14, automatic fallback for older versions)
MySQL / MariaDB MySQL 5.7+ · MariaDB 10.5+ (10.11+ for STATEMENT-level triggers)
SQL Server 2016+ (CREATE OR ALTER) — older versions partially supported

The CI runs every push/PR against the full matrix (PHP × Symfony × Platform × ORM 2 vs 3 × DBAL 3 vs 4 × with/without migrations-bundle), so you can rely on what is announced above.

🚀 Installation

1. Install the bundle

2. Register it in config/bundles.php

That's it — the bundle is ready to use with sensible defaults.

3. Optional — install Doctrine Migrations Bundle

Only needed if you want trigger changes to be automatically wired into Doctrine migrations (migrations: true in the bundle config):

Without it, the bundle works perfectly well: trigger files are still generated, and you can apply them via triggers:schema:update --force or by adding the SQL to your migrations manually.

⚙️ Configuration

The bundle ships with sane defaults — you don't need a config file to get started. To customize, create config/packages/trigger_mapping.yaml:

📚 More: docs/config.md

💾 The two storage strategies

You decide where the SQL of your triggers lives:

storage.type: 'php' (default) storage.type: 'sql'
What gets generated A PHP class implementing MySQLTriggerInterface, PostgreSQLTriggerInterface or SQLServerTriggerInterface with getTrigger() / getFunction() A .sql file (and a functions/<name>.sql file on PostgreSQL)
Where it lives App\Triggers\<TrgClassName> (configurable) %kernel.project_dir%/triggers/<name>.sql
Best for Static analysis (PHPStan/Psalm), refactoring, IDE-friendly DBAs editing raw SQL, psql -f-style workflows
Migrations integration addSql(\App\Triggers\Foo::getTrigger()) addSql(file_get_contents(__DIR__ . '/../triggers/foo.sql'))

You can also override the global setting per-trigger with #[Trigger(storage: 'sql')].

📚 More: docs/storing.md

🔀 Workflows

Scenario 1 — "I have a legacy DB with triggers I want to bring under version control"

The command will:

  1. List every trigger in the DB that has no #[Trigger] mapping yet
  2. Find the matching Doctrine entity (incl. ManyToMany join tables)
  3. Add the #[Trigger] attribute to that entity, with all params filled in from the DB
  4. Generate the corresponding PHP class (or .sql file) with the actual SQL logic from the DB

Your triggers are now version-controlled and reviewable — you can edit them just like any code.

Scenario 2 — "I want to add a new trigger to my application"

The interactive wizard asks for the entity, the trigger name, the events, the timing, etc., then:

Edit the generated getTrigger() body to put your real SQL, then run triggers:schema:update --force to deploy it (or run the migration in production).

Scenario 3 — "I changed an existing trigger and want to deploy it"

Edit the generated PHP class (or .sql file) and choose your deployment path:

Scenario 4 — "I want my CI to fail when DB and code drift apart"

Just add this step to your CI pipeline:

If any trigger is missing in DB, missing in mapping, or has divergent parameters, the command exits with a non-zero status code and prints a clear table of the discrepancies.

📜 Commands reference

Command Alias What it does
triggers:schema:validate t:s:v Compare mapping with DB and exit non-zero on drift. Read-only.
triggers:schema:show t:s:show Print the resolved SQL of mapped triggers. Read-only, no DB connection used.
triggers:schema:diff t:s:d Generate the missing trigger files / migrations from the mapping.
triggers:schema:update t:s:u Apply local trigger files to the DB (dry-run by default, use --force).
triggers:mapping:update t:m:u Import unmapped DB triggers into entity attributes.
make:trigger — Interactive wizard to scaffold a new trigger. Requires symfony/maker-bundle (dev).

All commands accept --entity App\Entity\Foo to scope to a single entity.

triggers:schema:validate

The "health check" for your trigger setup. Read-only. Reports four classes of problems:

📚 More: docs/schema_validate.md

triggers:schema:show

Prints the SQL that would be applied for each mapped trigger — without touching the database. Useful for:

triggers:schema:diff

Code-first companion of validate: takes every #[Trigger] that has no DB counterpart and scaffolds the file (PHP class or .sql) plus, if migrations: true, a Doctrine migration. The generated body contains a TODO placeholder — you fill in the real SQL.

📚 More: docs/schema_diff.md

triggers:schema:update

Deploys the trigger logic from your local files directly to the DB. Safer than it looks:

📚 More: docs/schema_update.md

triggers:mapping:update

Inspects DB-side triggers without a mapping and brings them into your codebase. Detects:

Triggers on tables that don't belong to any Doctrine entity are skipped with a warning (so DB extensions don't pollute your mapping).

📚 More: docs/mapping_update.md

make:trigger

Interactive wizard powered by symfony/maker-bundle. Step-by-step prompts for:

Validates each input early with friendly messages — invalid values throw \InvalidArgumentException with the list of allowed options.

📚 More: docs/make_trigger.md

🎯 The #[Trigger] attribute

The attribute is #[\Attribute(IS_REPEATABLE)] so you can stack multiple triggers on the same entity:

Validation rules (enforced at instantiation)

The constructor validates every value eagerly and throws \InvalidArgumentException on the spot — meaning typos surface at boot, not at runtime in production.

Field Rule
name, function, onTable Match /^[A-Za-z_][A-Za-z0-9_]{0,62}$/ (safe SQL identifier)
when One of BEFORE, AFTER, INSTEAD OF (case-insensitive)
scope One of ROW, STATEMENT (case-insensitive)
on[] Each item: INSERT, UPDATE, DELETE, TRUNCATE (case-insensitive)
storage php or sql (or null to inherit the global setting)

Why so strict? Identifiers end up in generated SQL files, file paths and PHP migration source. The strict regex closes a wide range of attacks (SQL injection through DROP TRIGGER, path traversal in storage paths, PHP code injection in generated migrations) at the boundary, in one place. See Security.

🐘🐬🪟 Multi-platform support

The bundle works the same on three platforms but each one has its quirks. Here is what is supported (and what is intentionally rejected):

PostgreSQL MySQL / MariaDB SQL Server
BEFORE / AFTER ✅ ✅ ❌ (rejected with a clear message)
INSTEAD OF ✅ (on views) ❌ ✅
Multi-events (INSERT OR UPDATE OR DELETE) ✅ ❌ (one event per trigger — rejected with a clear message) ✅
ROW / STATEMENT scope ✅ MySQL: ROW only · MariaDB ≥ 10.11: both STATEMENT only (per-statement triggers)
TRUNCATE event ✅ ❌ ❌
Trigger functions ✅ (separate pg_proc) n/a (body inlined in trigger) n/a (body inlined in trigger)
Multi-schema ✅ (current_schemas(false)) n/a ✅ (SCHEMA_NAME())
FK / partition triggers filtering ✅ (tgconstraint = 0, tgparentid = 0) n/a ✅ (parent_class = 1)
CREATE OR REPLACE TRIGGER PG ≥ 14 (auto-fallback to DROP + CREATE below) DROP + CREATE CREATE OR ALTER (SQL Server ≥ 2016)
Transactional deploys ✅ ❌ (DDL implicit commits) ✅

How extraction works

PostgreSQL triggers are decoded from the pg_trigger.tgtype bitfield — exact, no text parsing, no fragile regex. SQL Server reads sys.triggers + sys.trigger_events + sys.sql_modules.definition (scoped to SCHEMA_NAME()). MySQL/MariaDB reads information_schema.TRIGGERS (incl. ACTION_ORIENTATION for STATEMENT support).

⚙️ Doctrine Migrations integration (optional)

When doctrine/doctrine-migrations-bundle is installed and migrations: true is set in the bundle config, every triggers:schema:diff --apply and make:trigger --migration automatically generates a Doctrine migration with both the up() and down() statements:

Then deploy with the standard bin/console doctrine:migrations:migrate workflow — your triggers are part of the same atomic deployment as the rest of your schema changes.

⚠️ The generated SQL strings are produced via var_export() — which means even an attacker-controlled trigger name (e.g. coming from a compromised legacy DB) cannot break out of the string literal and inject PHP code into your migration files.

🛡️ Security

The bundle takes adversarial inputs seriously. Several mitigations are in place by default:

If you find a security issue, please report it privately via GitHub Security Advisories rather than a public issue.

🤝 Contributing

Contributions are very welcome. The full contribution guide — including how to run the test suite locally with Docker, how to install pdo_sqlsrv for SQL Server, how to use the Makefile shortcuts — is in CONTRIBUTING.md.

Quick start:

The CI runs every push/PR against:

📄 License

MIT © Clément Talleu and contributors.

All versions of trigger-mapping with dependencies

PHP Build Version
Package Version
Requires php Version >=8.2
symfony/console Version ^6.0 || ^7.0 || ^8.0
symfony/dependency-injection Version ^6.0 || ^7.0 || ^8.0
symfony/config Version ^6.0 || ^7.0 || ^8.0
symfony/http-kernel Version ^6.0 || ^7.0 || ^8.0
doctrine/dbal Version ^3.0 || ^4.0
doctrine/doctrine-bundle Version ^2.7 || ^3.0
doctrine/orm Version ^2.16 || ^3.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package talleu/trigger-mapping contains the following files

Loading the files please wait ...