Symfony Doctrine Sql Logger Bundle Laravel Package

Getting Started

The bundle is small and thin, so the fastest path is to read the source rather than guess at config keys.

1. Install and register. composer require --dev halloverden/symfony-doctrine-sql-logger-bundle. There is no Flex recipe, so add it to config/bundles.php manually:

   HalloVerden\DoctrineSqlLoggerBundle\HalloVerdenDoctrineSqlLoggerBundle::class => ['all' => true],
   

   Register it under ['dev', 'test'] only if you intend to keep SQL logs out of production.

2. Look here first, in order:

   • README.md — the only source of canonical config keys.
   • src/DependencyInjection/Configuration.php — the authoritative config tree (option names, defaults, whether it exposes log_level, log_channel, parameter logging, etc.).
   • src/Resources/config/services.xml (or services.php) — the service IDs you will later decorate or override.
   • src/ — whether it plugs in via the legacy SQLLogger interface or a DBAL Middleware; this determines which DBAL versions you can use.

3. Dump the reference before writing config. bin/console config:dump-reference <bundle_alias> gives you the exact YAML skeleton for the version you have installed.

4. First use case: in dev, route query logs to a dedicated sql Monolog channel so bound parameters, timings, and (optionally) a stack trace show up in var/log/dev.log alongside — but separable from — your application logs. That's the immediate win over Doctrine's default doctrine.dbal.logging, which just dumps statements into the generic doctrine channel.

Implementation Patterns

Dedicated channel, separate file. The most valuable day-to-day setup is a channel that can be tailed independently:

# config/packages/monolog.yaml
monolog:
    channels: [sql]
    handlers:
        sql:
            type: stream
            path: '%kernel.logs_dir%/sql.log'
            level: debug
            channels: [sql]

Then point the bundle's logger service at sql (inspect services.xml for the id — usually something like halloverden_doctrine_sql_logger.logger aliasing Psr\Log\LoggerInterface, or a dedicated LoggerInterface with the channel baked in via a monolog.logger.<channel> tag).

Scope it by environment. Enable the logger only where it earns its cost. In config/packages/dev/… and config/packages/test/… turn it on; leave prod with the bundle's default (off, or minimal). Do not rely on the bundle alone to disable itself — check Configuration.php for an explicit enabled flag and set it.

Avoid double logging. Doctrine already has doctrine.dbal.logging and doctrine.dbal.profiling. If you enable both this bundle and Doctrine's built-in logging you get every statement twice, once with parameters and once without. Pick one: this bundle for verbosity, Doctrine's flags off. The Symfony profiler's Doctrine panel is separate and can stay on — it's not the log file.

Correlate queries to requests. Add a Monolog processor that pushes a request id (or CLI command name) into the log record's extra. That turns a flat SQL log into something you can grep per request when debugging an N+1 or a slow endpoint. If the package already logs a stack trace, you can often drop it in favor of a request id and keep the log readable.

Filter to what matters. If the bundle exposes a threshold for slow queries, use it. If not, wrap or decorate its logger with a service that measures elapsed time and only forwards records above e.g. 50 ms. This is the one extension point worth building early — a 200 MB SQL log helps nobody.

Testing assertions. In functional tests, swap the bundle's logger for Symfony's TestLogger (or a spy implementing Psr\Log\LoggerInterface) and assert on context arrays — that the number of queries is what you expect, or that no query touched a certain table. It's a cheap regression guard for N+1 problems.

Middleware chaining (DBAL 3+ only). If the bundle registers a Doctrine\DBAL\Logging\Middleware, make sure your own middleware (e.g. a query-counting or read/write-splitting one) is registered adjacent in doctrine.dbal.middleware and not replacing it. Order matters: outer middleware sees the query before the inner one logs it.

Gotchas and Tips

• DBAL version compatibility is the first thing to check. SQLLogger was deprecated in DBAL 3 and removed in DBAL 4; Middleware is the supported path from DBAL 3 onwards. Read the library's composer.json constraints before upgrading Doctrine — this is the most likely breakage and the package has few users to file the issue first.
• Parameters can contain PII or binary data. Bound parameters include user emails, tokens, and BLOBs. In any shared or persisted environment, redact via a Monolog processor or disable parameter logging entirely. Binary values can also render as unreadable garbage in the log line.
• Silent log drops are almost always channel wiring. If nothing appears, check (a) the handler has channels: [sql] and the logger is tagged for sql, (b) the bundle is enabled in this env, (c) bin/console cache:clear after config edits — YAML in config/packages/ is compiled and won't hot-reload.
• Stack traces are expensive. If the bundle offers a trace option, keep it off by default; capturing a backtrace per query easily triples the overhead on a page with hundreds of statements. Turn it on ad hoc when chasing a specific culprit.
• Extension points: you can override the bundle's service class in config/services.yaml or, cleaner, decorate its service id (find it in services.xml). Decoration survives bundle updates; class override via parameters usually doesn't.
• Watch memory on long-running workers. A Messenger consumer or long CLI command with SQL logging enabled accumulates log records and context indefinitely. Either disable the logger for those commands or set a handler that rotates (rotating_file), not a plain stream.
• Don't expect deep feature parity with the profiler. This bundle is a focused logging shim, not a query analysis tool. For real profiling use the Symfony web profiler; use this bundle when you need the queries in a log file — CI output, a staging container, or a worker where the profiler isn't available.