Can Doctrine Migrations Detect Non‑Transactional DDL Automatically?

Goal

Ensure that a Doctrine migration can safely roll back a schema change without risking data loss or transaction failure.

Constraints & Uncertainty

Doctrine’s migration system exposes a transactional flag that defaults to true, wrapping the entire migration in a database transaction. The framework does not analyze the SQL to identify non‑transactional DDL statements such as CREATE INDEX on MySQL’s MyISAM engine. If such a statement runs inside a transaction, the database may raise an error, causing the migration to fail or leave the schema in an inconsistent state. Current practice requires developers to manually set transactional: false for migrations that contain unsupported DDL, but this introduces the risk of accidental data loss when the down method drops columns or tables.

There is no built‑in mechanism to preserve data modified during a migration when rolling back a column or table change, and the Doctrine roadmap has not yet decided whether to add automatic detection of non‑transactional statements.

Specific Questions

• Does Doctrine currently provide any mechanism to automatically detect non‑transactional DDL statements within a migration?
• Which database engines trigger transactional failures when non‑transactional DDL is executed inside a transaction, and how should migrations be configured for each?
• What would be required to implement automatic detection of non‑transactional statements in Doctrine Migrations, and how would that impact existing migration code?