Doctrine Migrations allOrNothing on MySQL: Implicit Commit Limitation

Doctrine Migrations allOrNothing on MySQL: Implicit Commit Limitation

When a Doctrine Migration runs on MySQL or MariaDB, the framework wraps the entire migration version in a transaction if allOrNothing=true. However, MySQL treats many DDL statements (CREATE, ALTER, DROP) as implicit commits, breaking the transactional guarantee. The migration remains marked as executed even if a subsequent postUp throws an exception, leaving the schema partially changed.

This behavior complicates zero‑downtime deployment strategies that rely on atomic schema changes. The question is whether Doctrine can provide a way to detect or suppress implicit commits for specific migrations, or if external tooling must be integrated to achieve true atomicity.

Key uncertainties:

• Does Doctrine expose any hook to disable the implicit commit behavior for a migration that performs DDL?
• Can the allOrNothing setting be dynamically adjusted based on the detected database platform?
• What is the recommended pattern to guarantee that a failed migration leaves the database in a clean state on MySQL?