- How do I install lfaveur/doctrine-migrations-multiple-database-bundle?
- Install it with Composer using composer require lfaveur/doctrine-migrations-multiple-database-bundle. Register the bundle in config/bundles.php if Symfony Flex does not do it automatically. Because it extends DoctrineMigrationsBundle, make sure doctrine/doctrine-migrations-bundle and doctrine/migrations are already installed and configured. Clear the Symfony cache after installation so the new container configuration and console commands are picked up.
- Which Symfony and Doctrine versions does this bundle support?
- The bundle builds on DoctrineMigrationsBundle, so its supported Symfony and Doctrine ranges follow that bundle plus your ORM and DBAL versions. Check the composer.json constraints in the repository and pin the release that matches your Symfony major version before upgrading. Always run your migration test suite on a staging copy of the database after a Symfony or Doctrine upgrade.
- How do I configure migrations for multiple entity managers?
- You declare one migration configuration per entity manager or connection, each with its own migrations path, version storage table, and connection reference. Keeping paths and tables separate means every database keeps an independent migration history instead of sharing a single version table. Point each configuration at the entity manager whose metadata it should diff against so generated migrations stay accurate.
- What is the difference between this bundle and DoctrineMigrationsBundle?
- DoctrineMigrationsBundle manages migrations for a single entity manager and a single migrations directory. This bundle extends it so several databases can be versioned and migrated independently through separate configurations and commands. Existing single-database setups continue to work, so you can adopt it only where a second connection is needed.
- Can each database have its own migrations path and versions table?
- Yes, that is the core purpose of the bundle: paths, version tables, and command namespaces can differ per connection. Unique version tables per database prevent one schema's migration state from blocking another's deployment. If several databases live on the same server, give each one a distinct table name to avoid collisions.
- Which console commands does the bundle add for each connection?
- The bundle exposes per-connection variants of the usual Doctrine migration commands such as migrate, status, diff, and generate. Command names typically include the connection name so you can target a specific database. Run bin/console list doctrine to see the exact command names available in your installed version before scripting deployments.
- Is this bundle compatible with Laravel?
- No, this is a Symfony bundle built on top of DoctrineMigrationsBundle, and its service container wiring will not load in a Laravel application. Laravel projects should use the framework's native migrations with the --database option to target multiple connections. Use this package only in Symfony applications that rely on Doctrine ORM and Doctrine Migrations.
- How do I run migrations for several databases during deployment?
- Call each connection's migrate command as a separate deployment step, in dependency order, and fail the deploy as soon as one step errors. Pass non-interactive flags so the commands run unattended in CI or a container entrypoint. Keeping steps separate makes it obvious which database failed and limits the blast radius of a bad release.
- How do I test migrations across multiple connections?
- Point each test environment at a dedicated database and run the per-connection migrate command during test bootstrap. Assert that each schema reaches the expected version and that migration paths do not overlap. Running the full multi-connection migrate from scratch in CI catches ordering problems that only appear on a clean database.
- Is the bundle actively maintained and what are the alternatives?
- Check the repository's release history, open issues, and last commit date on Packagist before adopting it, since maintenance activity matters for long-lived projects. Alternatives include running Doctrine Migrations programmatically with a separate DependencyFactory per connection, or splitting each database into its own Symfony application. For simple two-database setups, a light custom console command may be enough.