Database Extra Bundle Laravel Package

Getting Started

First, the important caveat: this is a Symfony bundle, not a Laravel package. It has no service provider, no config/database-extra.php, and no Artisan integration. It hooks into Symfony's Web Profiler and Doctrine DBAL. A Laravel developer can read it for ideas, but cannot composer require it into a Laravel app and expect it to work.

For a Symfony/Doctrine project the minimal steps are:

1. composer require --dev swis/database-extra-bundle
2. Symfony Flex auto-registers it in config/bundles.php; otherwise add Swis\DatabaseExtraBundle\SwisDatabaseExtraBundle::class => ['dev' => true, 'test' => true].
3. Add a dev-only config file, e.g. config/packages/dev/swis_database_extra.yaml:

swis_database_extra:
    # enable duplicate query detection and EXPLAIN support
    duplicate_query: true
    explain: true

4. Load a page with the profiler enabled, open the Database panel, and look for duplicated queries and an EXPLAIN action on slow statements.

Your first real use case: take a page that feels slow, open the profiler, find a query that runs N times, and click EXPLAIN to confirm whether it is doing a full table scan. That duplicate-query + EXPLAIN loop is the entire value proposition.

Implementation Patterns

Dev/test only. Register the bundle under dev and test in bundles.php. Never enable it in prod — the profiler data collector and EXPLAIN interception add overhead and can expose query text.

Duplicate-query hunting as a daily habit. Enable duplicate_query, then treat the Database panel as your N+1 detector. This mirrors what Laravel Debugbar does for you; if you are used to Debugbar, the workflow is identical, just inside Symfony's profiler.

EXPLAIN-driven optimization. Use the EXPLAIN action on any query that appears in the slow section. Check type, key, and rows on MySQL (or the plan nodes on PostgreSQL) before you start rewriting DQL.

Pair with Doctrine logging. The bundle is a thin layer on top of DBAL. Keep doctrine.dbal.logging: true in dev so the profiler has full query data to analyze; the bundle's duplicate detection depends on that stream.

CI guard (manual). There is no built-in "fail on duplicate query" assertion. If you want regression protection, wrap your functional tests so the profiler's duplicate-query count is asserted to be zero for critical endpoints — but you will be writing that glue yourself.

Laravel equivalent worth knowing. If you are staying in Laravel, the functional equivalents are barryvdh/laravel-debugbar (duplicate queries, timeline) and laravel/telescope (query history), plus a manual DB::select('EXPLAIN ...') or laravel-explain style helpers. Nothing in this bundle transfers directly.

Gotchas and Tips

• Not a Laravel package. No auto-discovery, no facade, no config publishing. Do not attempt to install it in a Laravel app.
• Maintenance risk is real. 3 stars, 0 dependents, low score. Treat it as unmaintained: pin the version, vendor it if you rely on it, and be prepared to fork. For a Laravel team this is a read-only reference, not a dependency.
• DBAL version coupling. It patches/intercepts Doctrine DBAL behavior. A DBAL major upgrade (3.x → 4.x) is the most likely breakage point. Test after every Doctrine bump.
• EXPLAIN is driver-specific. MySQL and PostgreSQL plans differ in shape and in what the panel can render. SQLite usually has no usable EXPLAIN output — don't expect the panel to be useful there.
• Profiler data exposure. Query text and parameter values land in the profiler storage. Keep the bundle dev-only and never expose the profiler in prod.
• Overhead. Query interception and backtrace capture are measurable on query-heavy pages. If dev feels slower with it on, that is the bundle, not your app.
• Extension points are limited. You can toggle duplicate_query / explain via config, but there is no documented event system for custom checks. Anything beyond the profiler panel means subclassing the data collector or writing your own DBAL middleware.
• Debugging tip: if the Database panel is empty, first confirm doctrine.dbal.logging and the profiler are both on, then confirm the bundle is registered for the current environment — the environment mismatch is the usual culprit.