CheckMigrated

[ajcvickers]

One of the dilemmas of "getting started" applications and examples is that creating the database in code when the application starts is by far the easiest way to get up and running with a database, but this is considered an anti-pattern for most production applications. So, even though its a bit harder, we want people to start with something like Migrations which allows us to show best practice from the start. However, using Migrations requires running some commands at the command line.

The idea behind EnsureMigrated is to have a single, simple line of code that can safely be run when starting an application and which will check if Migrations have been created and applied to the database. If no migrations are found in the project, then EnsureMigrated will stop and indicate that the user should run dotnet ef migrations add. For example:

A database must be created for this application. Enter the following commands to create a database using EF Core Migrations:
dotnet ef migrations add InitialMigration
dotnet ef database update
See https://aka.ms/databasemigrations for more information.

We can potentially also detect other conditions such as a migration exists, but update database has not been called. We may also want to check if the dotnet-ef tool is installed and give instructions for that.

To make this easier, we could create a new command that will add a migration and update the database in one go. For example:

A database must be created for this application. Enter the following commands to create a database using EF Core Migrations:
dotnet ef database initialize
See https://aka.ms/databasemigrations for more information.

The end-result is guidance towards best practice with minimal input from the user. It's also not magic--that is, the user knows that they are creating a database.

Thoughts @davidfowl @bricelam @JeremyLikness @halter73 @LadyNaggaga @glennc

[DamianEdwards]

This looks good @ajcvickers. What do you think we should do with regards to actually calling EnsureCreated then? Should it be our templates that use EF? Would we update the database exception filter for the developer error page to show the content you propose, along with details on how and where to call EnsureCreated? Of course getting the database exception filter registered is itself a manual task today which presents its own challenges WRT discovery (separate package, separate call to add the filter to services, etc.).

[bricelam]

This could leverage the API proposed in #22105 (comment) to check for unscaffolded migrations.

[bricelam]

📝 Design meeting notes

• The best name we could come up with was CheckMigrated()
• The method would throw when...
  • The database doesn't exist
  • There are unapplied migrations
  • There are pending model changes that you haven't added a migration for
• We should also update Migrate() to warn when you have pending model changes Warn on Migrate() when there are pending model changes #33732
• We still haven't forgotten about issues Migrations: Improve existing database support #2167 and More streamlined workflow for early stage app development #3053 which would also help smooth the evolution of apps from prototype to production. These might enable a new method on DbContext.Database which would help users get up and running faster and guide them through the steps of evolving their workflow.

[ErikEJ]

"VerifyMigrated" ?