Database migrations

[rbs]

System Information

• Strapi Version: 4:
• Database: MySQL:

---

As you know, a database migration process is necessary for each deployment of a new version that modifies the database schema. I am new to Strapi, and my question is concerning this point.

Knowing that this modification is always done in a visual way from the Strapi admin dashboard (for example by adding a collection or a link between two collections: which generates the creation of a tables at the database level). I imagine it’s faster, easier, and more secure to let the core of Strapi create this db migration file automatically for us. But I don’t know if this already implemented.

Is this currently possible via some configuration setup. Or should we implement this file (as suggested by this page) which could be quite complicated?

If the single way to have database migration files is by writing them from scratch, could you please share your best practice or tricks for that ? For my part I can imagine versioning the schema of the db in sql, before and after the modification and making a comparison of the two files to know what was modified and subsequently implementing it in Knex…

In short, how, guys, are you doing at the moment to manage the migration of the db with each integration of a new version that affects the schema of the db?

THX

[Boegie19]

When strapi restarts it will check all its own stuff and strapi will drop any table it does not know.
migrations would only be for example if you rename a column and it deletes your data then you need to migrate it over manualy from the old table name to the new one

[rbs]

Hi @Boegie19

If I summarize what I understand from your message:
There is already a Strapi DB migration process that will be triggered when Strapi starts, even without adding migration knex.js scripts.
This will detect added and deleted parts (tables, fields,…) from DB then automatically migrate the database. But some operations such as renaming of fields are not well handled by current the Strapi DB migration process.

Apart from renaming, what are the other operations that are not well handled by Strapi DB Migration Process?

As you know this requires good understanding, because we could easily screw up the production data:

• Do you know of a page (url) where this subject is discussed in more detail?
• Could you please share the steps of your migration strategy.

Many thanks

[Boegie19]

see for more information

Documenting the Automated Schema Migrations

Thanks. In my original post I meant to link to Database migrations | Strapi Documentation but I put the : at the end of the URL instead of putting a space before the colon. My guess is that something like this happens when the Strapi app starts. But I want more clarification: first it finds all of the migration files in ./database/migrations . Then it checks the database to see if any of those have not been run yet Any of those migration files for the current environment that haven’t been run…