Can Doctrine Migrations Detect Non‑Transactional DDL Automatically?

Direct Answer

No. Doctrine Migrations does not analyze the SQL inside a migration to detect non‑transactional DDL statements. The only control is the transactional flag on the migration class, which defaults to true. You must set transactional: false yourself when a migration contains statements that the target database engine cannot run inside a transaction.

Engine‑Specific Behavior

Engine	Transactional DDL Support	Typical Failure Mode	Required Config
MySQL InnoDB	Most DDL (CREATE/DROP TABLE, ALTER TABLE, CREATE INDEX) is transactional	Rare; only a few statements like CREATE DATABASE or DROP DATABASE are non‑transactional	Leave transactional: true (default)
MySQL MyISAM	No DDL is transactional	Implicit commit before/after each DDL; transaction rolls back with error	Set transactional: false
PostgreSQL	Most DDL is transactional, but CREATE INDEX CONCURRENTLY, VACUUM, CREATE DATABASE, DROP DATABASE are not	ERROR: cannot run CREATE INDEX CONCURRENTLY inside a transaction block	Set transactional: false for migrations containing those statements
SQLite	DDL is transactional in modern versions, but VACUUM, ATTACH/DETACH DATABASE, and some pragma statements are not	Transaction rollback or SQLITE_ERROR	Set transactional: false when using non‑transactional pragmas or VACUUM
SQL Server	Most DDL is transactional; CREATE DATABASE, DROP DATABASE, and full‑text catalog commands are not	Error 3902: The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION	Set transactional: false for those specific commands
Oracle	DDL issues an implicit commit; cannot be rolled back	Implicit commit ends the transaction; subsequent rollback has no effect on DDL	Set transactional: false (DDL never rolls back anyway)

What Automatic Detection Would Require

1. SQL parsing per dialect – A parser that understands each engine’s grammar and knows which statements are non‑transactional for that engine.
2. Engine awareness – The migration runner would need the target platform (e.g., mysql, postgresql) at analysis time, not just at execution time.
3. Heuristic or declarative hints – Because raw SQL can be generated dynamically (via addSql() with parameters), static analysis cannot be 100% reliable. A fallback would be a new annotation like @nonTransactionalStatements or a method override.
4. Backward‑compatibility layer – Existing migrations rely on the explicit transactional flag. Any auto-detection would need to default to the current behavior unless opted in, otherwise it would silently change rollback semantics for existing projects.

Impact on Existing Migration Code

• If detection were added and enabled by default, migrations that currently set transactional: false manually would see no change.
• Migrations that omit the flag (relying on the default true) but contain non‑transactional DDL would suddenly start failing at analysis time instead of at runtime—arguably an improvement, but a breaking change for CI pipelines that don’t run the new analyzer.
• Projects using dynamic SQL ($this->addSql(sprintf(...))) would get false negatives unless they also adopt declarative hints.

Practical Recommendation Today

1. Audit each migration for statements known to be non‑transactional on your target engine (see table above).
2. Add protected $transactional = false; to those migration classes.
3. For migrations that drop columns or tables with transactional: false, implement a down() that restores data from a backup table or uses a separate data‑migration step, because a failed rollback cannot be wrapped in a transaction.
4. Run doctrine:migrations:migrate --dry-run against a staging database matching production’s engine and version to verify behavior before deploying.

One Diagnostic Detail Needed

Which database engine and version are you targeting in production? The exact list of non‑transactional statements differs between MySQL 5.7 vs 8.0, PostgreSQL 13 vs 16, etc., and that changes which migrations need transactional: false.