- What is firehed/dbal-logger and what problem does it solve?
- It is a framework-agnostic Doctrine DBAL middleware that replaces the deprecated SQLLogger. It captures executed SQL, bound parameters, and execution times through a PSR-3 logger. It is useful when you need query visibility on a Doctrine DBAL connection during the DBAL 3 to 4 transition or in a non-Eloquent stack.
- Does firehed/dbal-logger work with Laravel?
- It can work in Laravel only if your query traffic goes through a Doctrine DBAL connection. It is not a Laravel package and does not instrument Eloquent or PDO queries by itself. For normal Eloquent queries use DB::listen(), QueryExecuted, or Laravel Telescope instead. DBAL may appear in Laravel via schema operations, migrations, or packages that own a DBAL connection.
- How do I install and configure firehed/dbal-logger?
- Install with composer require firehed/dbal-logger. Instantiate the middleware with a PSR-3 logger and register it on the Doctrine DBAL Configuration using setMiddlewares(). In Laravel you would typically do this in a service provider for the specific DBAL connection that needs logging. Pin the package and DBAL version together and cover the pairing in CI.
- Which Doctrine DBAL versions does firehed/dbal-logger support?
- It is designed as a DBAL middleware for DBAL 3.x and 4.x, where SQLLogger was removed. Middleware signatures have shifted across DBAL minor versions and 4.x, so you must pin DBAL and the package together. Verify the supported constraint on Packagist and test the exact pairing in CI before relying on it.
- Is firehed/dbal-logger a replacement for Laravel Telescope or DB::listen()?
- No. Telescope and DB::listen() observe Laravel's PDO/Eloquent query path, while this package observes Doctrine DBAL connections. If your application is Eloquent/PDO-only, the middleware is inert for your normal query traffic. Use it only when you have a DBAL connection that lacks query observability or during a DBAL 4 migration.
- What are the production risks of logging bound parameters with firehed/dbal-logger?
- SQL loggers capture bound parameters, which often contain PII, tokens, or session identifiers. An unredacted logger can create a compliance finding, so build an allowlist or redaction layer before logging parameters. Also wrap logger calls defensively so a logging exception cannot fail the query being observed. Consider sampling to control volume and exposure.
- How do I test firehed/dbal-logger in a Laravel or PHP application?
- Use a PSR-3 test logger or in-memory logger to assert that queries, parameters, and timings are emitted. Register the middleware only on a non-production DBAL connection for the spike and confirm queries emit as expected. Add CI coverage for the pinned DBAL and package versions, and include a redaction test if you log parameters.
- Is firehed/dbal-logger actively maintained and safe to depend on?
- The package is small, MIT-licensed, and has very low adoption with a single maintainer, so community validation is limited. Because it does one narrow thing, forking or vendoring the middleware into your own namespace is a credible fallback. Verify the latest release date on Packagist before treating it as actively maintained, and plan ownership for a fork if upstream goes quiet.
- What alternatives exist to firehed/dbal-logger for Doctrine DBAL query logging?
- For Laravel Eloquent/PDO use DB::listen(), QueryExecuted, or Telescope. For Doctrine DBAL, DBAL middleware is the sanctioned extension point now that SQLLogger is deprecated or removed; you can also write your own small middleware or use a profiling tool. This package is best seen as a migration bridge or a narrow DBAL observability shim, not a full profiling platform.
- When should I adopt firehed/dbal-logger versus decline it?
- Adopt only if you are mid-migration to DBAL 4 and need parity with the removed SQLLogger, or if you have a non-Eloquent DBAL connection with no query observability. Decline if your production read/write path is exclusively Eloquent/PDO, because DB::listen() already covers it. Record the decision and the reason either way; negative evaluations are cheap.