Question concerning propel-migrations

s.kroll

Hello everyone,

a general question concerning propel-migrations, maybe even addressed to spryker-core devs directly:

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

Andriy Netseplyayev

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

giovanni.piemontese

Follow 🤔

UK7KBE2JW

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?

s.kroll

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.

Andriy Netseplyayev

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

s.kroll

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.