Updating the DataModel and or Database Schema - PuzzleServer/mainpuzzleserver GitHub Wiki

The server uses Entity Framework Core 5, which depends on "Migrations" to update the database. For more details see this page: https://docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/

Migrations are automatically deployed at startup if the site is running in debug, so in most cases only the person making the schema changes needs to take any action.

Please avoid breaking changes whenever possible - breaking changes happen in development but they can be a huge hassle in production, so follow best practices for changes that affect the database schema.

If you add a new property to any data model class and the property is a custom/complex object type, you must make it virtual so that it can be loaded indirectly (more details: https://docs.microsoft.com/en-us/ef/core/querying/related-data).

If you make changes to any of the classes in the DataModel and do not want the changes to be reflected in the database you need to use the [NotMapped] attribute. Any properties marked with that attribute are not added as columns in the table.

If you make changes to any of the classes in the DataModel and DO want the changes to be reflected in the database you need to complete the following steps:

  1. Open the Package Manager Console in Visual Studio (Tools -> NuGet Package Manager -> Package Manager Console)
  2. Change the default project in the Package Manager Console header to "Data"
  3. Run the command "Add-Migration <UsefulName>" where <UsefulName> is a unique name that acts as a short summary of the migration (e.g. the existing migration is CreateDb and was created by running the command "Add-Migration CreateDb"). If successful this command will generate a cs file in the DataModel/Migrations folder. This file must be checked in with the DataModel changes.

If you are preparing for a production deployment you must also run the Script-Migration command. See the above reference page for more information (odds are good that you will not need to do this, it will only be done by the person creating the package for deployment). Create an idempotent SQL script - using that setting will make sure that the script runs exactly the migrations needed regardless of the current state of the database.