Migration and table content manipulation

💻 Development
1

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, pre-migration and post-migration triggers will kick in on every migration, which is not desirable for any of the above cases. install and uninstall are also not useful for system change or development. The same goes for live-migration, which 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 preMigrationStep and 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 :slight_smile:

2

Followup: a solution could be to instantiate inside postMigrationStep a class that extends IRepairStep, only I can’t see how to supply it with an IDBConnection object.

3

A migration class may have an IDBConnection object injected. The connection may be passed in the postMigrationStep method to the constructor of a desired class implementing IRepairStep.

An example of this procedure can be admired in apps/dav/lib/Migration/Version1008Date20181105110300.php.

Problem solved for me. I believe a little note or example in the dev docs might be helpful to others, though.