Database migrations

Whenever a change to the database model is made, it is necessary to generate a migration using the EF Core tools. This allows for the database schema to be updated based on the new model.

Creating a migration

Due to the split-project setup of the solution, additional arguments need to be passed to dotnet ef migrations add. It needs -s to specify the startup project as DragaliaAPI.csproj due to this project having ApiContext in the service container, but it also needs -p to specify DragaliaAPI.Database.csproj as the project containing the database model. You can skip one of these arguments by running the dotnet ef command inside either the main project folder or the database project folder, and then you only have to supply the relative path to the other project file. For example, from the database project folder you can run:

dotnet ef migrations add name

Or you can explicitly specify the path to the database project to both -s and -p.

Naming convention

Migrations should be named after the feature they concern, e.g. they are applied against, and there is then a suffixed number to differentiate subsequent migrations in a version. Note that the EF Core tools will automatically prefix a timestamp. For example:

20231204191101_WeaponPassives.cs
20231210194604_DailyMissions.cs

Applying a migration

If the PostgresOptions.DisableAutoMigration configuration value is not set to true via appsettings or env variables, then migrations are applied automatically on startup. In other words, you don't have to worry about applying migrations manually in the development environment.

If you wish to deploy to production, you may find this resource from Microsoft about managing migrations to be useful. The recommended way is with SQL scripts that are carefully reviewed to ensure no data loss occurs, and of course with plenty of backups. The main deployment uses auto-migration and has not had any issues so far, however.