Hello everyone,
Is there a reason why the default install-scripts of the suites clear all existing migrations in the beginning (see: https://github.com/spryker-shop/b2b-demo-shop/blob/8c21e264eb4318b6605465762c2ea00413ba8890/config/install/EU/production.yml#L13)?
Is there another recommended way to run custom migrations on deploy (before the automatically generated ones)?
We e.g. want to rename a column which is not directly supported via propel's schema-xmls afaik. propel:diff
would simply drop the old one and create a new one so all data would be lost
No one stops you from removing this command from the yml file and start commiting your migrations to the codebase. You only need them if you want to run custom SQL migrations (manually introduced/updated). We had that on couple of projects - works perfectly fine.
Another way would be to create a console command, maybe even parametrised (if you see a need in re-usage) and just execute it via jenkins, when needed (also used on some projects)
And one more way - is to use “installer plugins” (runs with the command setup:init-db
) - but it’s purpose is to seed the “system” data that is not relevant for data-import
Follow 🤔
How about letting the old field like it is, create the new one and create a sql snipped moving data from old field to new field?
This was also a possible workaround we considered @UK7KBE2JW, but ... it is a workaround 😄 We are still interested in manual/custom-migrations, not exclusively for the "rename"-problem mentioned above.
No one stops you from removing this command from the yml file and start commiting your migrations to the codebase. You only need them if you want to run custom SQL migrations (manually introduced/updated). We had that on couple of projects - works perfectly fine.
Another way would be to create a console command, maybe even parametrised (if you see a need in re-usage) and just execute it via jenkins, when needed (also used on some projects)
And one more way - is to use “installer plugins” (runs with the command setup:init-db
) - but it’s purpose is to seed the “system” data that is not relevant for data-import
Thanks for your response @UKJSE6T47. We thought of just removing the initial migration:delete
but we were curious why it was there at all. Must have had a reason 😉
I think we will go the custom-command approach which gives us control on how and when we run it.