Alternate Folder Structure for Schema Migrations

jimohalloran commented 3 years ago

Summary
A bundle that has a large number of schema migration versions eventually become unwieldy because of the large number of folders in the Migrations/Schema folder. Everything still works, it's just awkward to deal with (especially in graphical IDEs).

You can see an example of this problem in the Magento 1 bundle for OroCRM where there's 62 migration folders today... https://github.com/oroinc/orocrm-magento1-connector/tree/master/src/Oro/Bundle/MagentoBundle/Migrations/Schema . Due to customer requirements constantly changing schema, one of my bundles have 77 migration folders today.

To help make this more manageable I propose the addition of an alternate folder structure vMajor/Minor/Patch.

Example

In addition to the current vMajor_Minor_Patch (e.g. v1_50 or v1_50_1) structure, I propose the OroMigrationBundle be extended to also allow vMajor/Minor/Patch or vMajor/Minor_Patch (e.g. v1/50 and v1/50/1 or v1/50_1).

If the OroMagentoBundle migration versions roughly tracked the release version (incrementing the Major version when the major product version changed, even if minor and patch numbers didn't match the release version exactly) this would help make the migrations for this bundle more manageable by putting all of the migrations added in v5 of the product in their own folder. Also, due to the need to support existing customers upgrading from old version of OroCRM, the CRM team can't simply squash all of their exsiting migrationjs into an installer and delete the migrations. The individual migrations need to be present, so the number of folders in Migrations/Schema will only grow over time.

In the case my bundle with 77 migrations, this would mean I could start a new major version with it's own folder periodically to keep the number of subfolders in each manageable. I don't want to delete my old migrations because I'd like to retain the ability to recreate a unit test database from scratch by running all of the migrations again. I'm wary about creating an installer to replace my 77 existing migrations because it will be difficult to ensure that the results of the migrations vs the installer are identical. It would be much easier to simply organise my migrations into a folder structure.

Moving migrations into subfolders is a low risk change as it's just renaming existing folders. The alternate solution of creating an installer to "roll up" all of the changes carries substantial risk as ensuring both the original migrations and the installer (even if generated by oro:migration:dump) creates identical schema is difficult.

jimohalloran commented 3 years ago

mbessolov commented 3 years ago

I see no problem with that as long as it preserves the old way as well. You are welcome to create a PR.

oroinc / platform

Alternate Folder Structure for Schema Migrations #1057