Question
Magento 2 Declarative Schema Rollback Safety for Destructive Changes
Kavi Dey
0 reputation · 21 Aug 2022, 19:10 UTC
87.2K views
Loading…
0 reputation · 21 Aug 2022, 19:10 UTC
Magento 2 applies declarative schema changes from etc/db_schema.xml during schema upgrade and records the applied module version in setup_module. The platform does not provide a native down migration or rollback command for schema changes.
Once a destructive change such as dropping, renaming, or narrowing a column is applied, reversing it requires manual SQL or a new forward patch. A module owner wants to declare that a schema change is reversible only when a matching rollback patch exists, but Magento does not validate this pairing before marking the version as applied.
Assumes Magento 2.4.x declarative schema behavior. Can a custom extension intercept declarative schema changes and apply a compensating rollback without corrupting module version tracking? Should Magento require a rollback patch for destructive db_schema.xml changes before the upgrade completes? Which MySQL DDL behaviors affect whether a manual rollback preserves existing data?
Magento 2 marks the module version in setup_module after applying declarative schema changes from etc/db_schema.xml, but provides no native rollback mechanism. When a destructive change such as dropping or narrowing a column is applied, reversing it requires manual SQL or a forward patch.
magentoDROP COLUMN discards column data; RENAME COLUMN preserves it; TYPE changes to a smaller size may truncate existing values.A custom module can implement a DataPatch or hook ResourceConnection::setupUpgrade to execute compensating SQL after the schema change. To avoid version tracking corruption, the patch must either prevent the version increment (via a plugin) or decrement the setup_module row after the rollback SQL runs. Without this, the module appears upgraded while the schema is reverted, causing future upgrades to behave unexpectedly.
setup_module version for the target module.ALTER TABLE ... ADD COLUMN, RENAME COLUMN back, or restore type).SHOW CREATE TABLE and confirm data integrity.setup_module to the previous version; otherwise, revert the transaction and investigate.Missing diagnostic detail: Which MySQL version and column type are involved? DROP COLUMN behavior is irreversible by default, whereas RENAME COLUMN and reversible TYPE changes depend on existing data constraints.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 21 Aug 2022, 22:47 UTC
A critical distinction when attempting to make destructive changes reversible is the behavior of \Magento\Framework\Setup\Patch\RevertableInterface. While this interface allows you to define a revert() method to execute compensating DDL, it does not automatically decrement the module version in the setup_module table.
Because Magento's declarative schema and patch system are designed as forward-only versioning, reversing a destructive change via a patch leaves the system in a state where the version is still marked as "applied." This creates a specific risk: if you manually downgrade the version in setup_module to force a re-run of the schema upgrade, you may inadvertently trigger other pending patches or skip necessary data migrations.
It is also worth noting that for narrowing columns (e.g., VARCHAR(255) to VARCHAR(50)), a revert() method can restore the column length, but it cannot recover data truncated by MySQL during the initial forward application. True safety for destructive changes requires a data migration patch to backup values to a temporary table before the db_schema.xml change is applied.