I understand that
MigrationStep updates the DB schema and
RepairStep operates on DB tables and data. In some cases a combination of both is desired, for instance if
- an existing table is to be split in two and table content needs to be moved
- a new table is to be primed with entries
- a table becomes obsolete and should be dropped to free memory
- a table shall be filled with data from a remote system
RepairSteps need to be registered in
info.xml, making them a recurring thing rather than a one-shot action for a specific migration step. This seems to be incompatible with controlled system improvement, not to mention development.
As for the triggers,
post-migration triggers will kick in on every migration, which is not desirable for any of the above cases.
uninstall are also not useful for system change or development. The same goes for
crons the repair step.
Is there a preferred way of doing this, anything I missed?
In the unlikely case that there is not, I would like to propose making
RepairStep accessible from
postMigrationStep so that a specific migration step may carry out some associated data manipulation.
At least there could be support for manually launching a
RepairStep without registering it for repeated execution.
Comments and ideas welcome