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 https://github.com/dotnet/efcore/issues/22105#issuecomment-675146504 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 #33732
• We still haven't forgotten about issues #2167 and #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" ?

[vigouredelaruse]

please advise of a better discussion thread for the following

re: automatic creation of azure resources, specifically today referencing azure sql database (excluding managed instances, caveated here https://techcommunity.microsoft.com/t5/azure-sql-blog/what-azure-permissions-are-required-to-create-sql-managed/ba-p/386275)

a cursory investigation will show that database resource deployment in azure depends on an intersection of permissions

• azure policy
• azure arm
• azure sql user permissions

azure policy permits macro governance and the document here https://learn.microsoft.com/en-us/azure/azure-sql/database/policy-reference?view=azuresql has the following to say about azure policy and azure sql database

• Azure Policy applicable to a Azure SQL Database creation is not enforced when using T-SQL or SSMS.

i am seeking clarity on the possible effects of careless invocations of .ensuredeleted(), .ensurecreated() and/or .ensuremigrated() because er, i have such code

in the form of a question: given

• an entity framework core app
• running against azure sql database
• authenticated with a user who does not have sql drop database or create database privs

is it reasonable to expect that developers cannot 'accidentally' spin up arbitrary azure sql server instances by using .ensurecreated() or .ensuredeleted() and/or .ensuremigrated()

please advise on the case where authentication is done with sa or some sql login account with [database drop, database create] let's say

thanks