Hi, @Jantero93 - to try to generalise a bit, how do you run your EF migrations? It looks like the recommended way from Microsoft to run EF migrations in production is to generate SQL scripts:
It even looks like they have some functionality similar to grate, with the Idempotent SQL scripts (same page, further down).
Microsoft says in this same page:
The EF command-line tools can be used to apply migrations to a database. While productive for local development and
testing of migrations, this approach isn't ideal for managing production databases:
The SQL commands are applied directly by the tool, without giving the developer a chance to inspect or modify them. This can be dangerous in a production environment.
The .NET SDK and the EF tool must be installed on production servers and requires the project's source code.
I would recommend:
As part of your development or CI workflow, generate SQL scripts from EF migrations, using dotnet ef migrations script (optionally with from and to parameters
Store the scripts in the grate up folder, numbered in ascending order (maybe in a sub-folder per generated migration if there are many scripts generated), so that each migration will be applied in the correct order when you run grate
Depending on the rest of your grate scripts, where they fit in with the EF migrations, you might want to use another folder than up for the EF migrations scripts, if you always want to run these before the other migrations. But I would definitely recommend using a one-time-scripts type of folder for EF migrations, as this fits well with how EF migrations work.
Hi, @Jantero93 - to try to generalise a bit, how do you run your EF migrations? It looks like the recommended way from Microsoft to run EF migrations in production is to generate SQL scripts:
https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/applying?tabs=dotnet-core-cli
It even looks like they have some functionality similar to grate, with the Idempotent SQL scripts (same page, further down).
Microsoft says in this same page:
I would recommend:
dotnet ef migrations script(optionally withfromandtoparametersupfolder, numbered in ascending order (maybe in a sub-folder per generated migration if there are many scripts generated), so that each migration will be applied in the correct order when you run grateDepending on the rest of your grate scripts, where they fit in with the EF migrations, you might want to use another folder than
upfor the EF migrations scripts, if you always want to run these before the other migrations. But I would definitely recommend using a one-time-scripts type of folder for EF migrations, as this fits well with how EF migrations work.You can customise the grate Folder configuration completely, if you want either a simpler or more complex folder structure than the default: https://erikbra.github.io/grate/folder-configuration/