Question concerning propel-migrations

s.kroll
s.kroll Head of Technology Spryker @ basecom Posts: 117 ✨ - Novice
edited June 2023 in Propel ORM

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

Tagged:

Best Answer

  • Andriy Netseplyayev
    Andriy Netseplyayev Domain Lead Solution Architecture Sprykee Posts: 517 🧑🏻‍🚀 - Cadet
    Answer ✓

    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

Answers

  • giovanni.piemontese
    giovanni.piemontese Technical Lead @ Löffelhardt Spryker Solution Partner Posts: 871 🧑🏻‍🚀 - Cadet

    Follow 🤔

  • UK7KBE2JW
    UK7KBE2JW Posts: 463 🧑🏻‍🚀 - Cadet

    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
    s.kroll Head of Technology Spryker @ basecom Posts: 117 ✨ - Novice

    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
    Andriy Netseplyayev Domain Lead Solution Architecture Sprykee Posts: 517 🧑🏻‍🚀 - Cadet
    Answer ✓

    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
    s.kroll Head of Technology Spryker @ basecom Posts: 117 ✨ - Novice

    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.