- How do I add a database trigger to a Laravel migration with this package?
- Install it with Composer (composer require ntimyeboah/laravel-database-trigger) and use the package's artisan generator to scaffold a migration that creates the trigger, then run php artisan migrate. The migration puts CREATE TRIGGER on the same versioned, ordered path as your tables and indexes instead of a hand-run SQL script or an ad-hoc DB::unprepared call. The trigger body itself remains SQL you write, so the package handles creation, naming, and drops rather than generating trigger logic for you. Check the README for the exact generator command signature.
- Which database drivers does laravel-database-trigger support?
- MySQL is the de-facto target, and support for other engines depends on the version, so read the README and the CI matrix before assuming Postgres parity. Trigger bodies are raw, dialect-specific SQL, so nothing in the package makes a MySQL trigger portable to Postgres or SQLite. If you deploy against more than one engine, plan to maintain separate trigger definitions rather than expecting one migration to cover both.
- Does it support Laravel 11 and Laravel 12?
- Check the composer.json constraints for illuminate/database and PHP before installing, since the package was first released in February 2025 and newer Laravel majors may not be declared yet. Require it on a scratch branch first and confirm the constraint resolves against your Laravel version. If Laravel 12 is not covered, the code surface is small enough that vendoring the classes into app/ and adjusting them is a realistic option.
- How do I test database triggers with RefreshDatabase and in-memory SQLite?
- Triggers are not exercised by in-memory SQLite, so any suite running RefreshDatabase against SQLite silently loses all trigger behavior and the tests pass without covering it. Point the tests that touch trigger-driven logic at the same engine you deploy on, MySQL or Postgres, running as a service in CI. This is an environmental constraint rather than a package bug, but the package does nothing to mitigate it, so budget for a second database service in your pipeline.
- Does the generated migration roll back and drop the trigger?
- The generator is intended to emit a matching DROP TRIGGER in down() so the migration is reversible, but verify that in a scratch environment before trusting it in a release. Rollback semantics also differ by engine: Postgres DDL is transactional, while MySQL performs an implicit commit, so rollback-on-failure does not behave the same way on both. Run a migrate and rollback cycle as part of your review.
- What database privileges are needed to create triggers from a migration?
- The migration user in CI and production needs the TRIGGER privilege on MySQL, or table ownership or CREATE TRIGGER on Postgres. Many least-privilege and managed-database setups do not grant that to the application's deploy role, which turns a working local migration into a failed production deploy. Confirm the grant with whoever owns the database before you ship the migration.
- Will triggers survive schema:dump, squashing, and migrate:fresh?
- Verify this explicitly: run schema:dump or migration pruning, then migrate:fresh in a clean environment and check that your triggers still exist. If triggers are dropped or omitted from the squashed schema, fresh environments silently lose behavior with no error at all. A cheap safeguard is a smoke test or deploy check that asserts each expected trigger is present.
- Is this package production-ready, and what is the maintenance risk?
- Treat it as a small convenience wrapper backed by a single maintainer: roughly 20 stars, a first release in February 2025, and a bus factor of one. MIT licensing and a small code surface make vendoring the handful of classes into app/ cheap insurance, and that should be the default assumption in your risk model. Pin the version in composer.json and read the code you depend on before rolling it out.
- How is this different from writing DB::unprepared('CREATE TRIGGER ...') in a migration?
- A hand-written migration containing DB::unprepared with a CREATE TRIGGER plus a matching DROP TRIGGER in down() is roughly 15 to 25 lines. The package's genuine gain is ergonomics, namely a generator scaffold with naming and rollback conventions, not a real abstraction over trigger DDL. If you only need one or two triggers, raw SQL inside a migration is a perfectly reasonable alternative.
- Can it update an existing trigger, and does it detect drift from the database?
- Redefinition differs by engine: Postgres supports CREATE OR REPLACE TRIGGER while MySQL requires a drop-then-create, so confirm the generated SQL is idempotent for your driver. There is no built-in drift detection between the trigger that exists in the database and the one defined in your migrations, so a trigger edited directly in production will not be flagged. If that matters, add a verification command or schema assertion to CI, and remember that Eloquent models give no hint that trigger logic exists.