Clever Geek Handbook

Command line connection string to update EF database

Using ASP.NET Core and EF Core I am trying to apply migrations to a database. However, entering the connection string into appsettings.json

which the application will use only has CRUD access due to security concerns, so it cannot create tables and columns, etc. So when I run:

dotnet ef database update -c MyDbContextName -e Development

I mean it uses a different connection string, but I don't know if it can be done? Basically, I want to use two different connection strings, one for deployment and one for launching the application. Is it possible? Is there a better approach? Thank.

+8


source to share


2 answers


Save both connection strings to appsettings.json

. Inherit the child context class from the main one and override with a OnConfiguring

different connection string:

public class ScaffoldContext : MyDbContextName 
{
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        string scaffoldConnStr = ConfigurationManager.ConnectionStrings["scaffoldConnStr"].ConnectionString;

        optionsBuilder.UseSqlServer(scaffoldConnStr);
    }
}


Then use:

dotnet ef database update -c ScaffoldContext
+8


source


I liked the idea of ​​creating a DbContext forest, but I found some problems (somehow solvable I think) as well as some thought about where to store the connection strings. I was led to a different, rougher solution, so I thought I'd cover it all here.

This concerns the general approach and subsequent decision:

  • I don't like keeping strings for staging / production connection under source control. So I would pass this through an environment variable set in a temporary command window (or maybe on the fly on the command line, although I couldn't get the job done). At this point, if I set an environment variable, I could also override the initial connection string used MyDbContextName

    instead of adding a new one. So the entire forest database context can be traversed in this way.


Other problems I found along the way:

  • In the original DbContext, dependencies were injected into the constructor, so the detailed context had to do the same. This made the teams dotnet ef

    complain about the lack of a parameterless constructor.

  • To overcome this, the child context was also registered when started with .AddDbContext<ChildDbContext>(...)

    . This also required the ChildDbContext to be injected with DbContextOptions<ParentDbContext>

    as well as with DbContextOptions<ChildDbContext>

    . After doing this dotnet-ef

    , I still found issues with instantiating ChildDbContext as it also needs a dependency on IConfiguration

    it that cannot be found. Maybe (?) This is due to the fact that it dotnet-ef

    does not run through the entire launch of the application.

As I said, I think the problems can be solved eventually, but still I question the real value of the forest context in case you don't want to store connection strings in dedicated appsettings files. One counter argument might be that you can forget the environment variable set to the remote connection string, but then you just need to close the command prompt window as soon as you complete the migration. NTN

+1


source






More articles:


All Articles