It is open question just to understand is it possible or not as i am new to .net core.
I add migration in .net core and then i have a code in start of the application.
context.Database.Migrate();
This automatically runs the pending migration and migration is applied on to the database at the start of the application.
Now here is scenario.
Is it possible that i skip this automatic migration but have some page where i can see pending migration and apply the pending migration by executing some methods ?
Thanks!
Related
The documentation for Entity Framework says to use migration CLI commands to create a database that doesn't exist yet for our EF model, and sync a database when our EF model changes.
Why do we need to explicitly run CLI commands outside our application in order to handle migration?
Can our applications that use EF implicitly handle migration: create a database if it doesn't exist for our EF model and sync a database when our EF model changes?
I had a little experience with Hibernate before, and I didn't hear about migration then. I might be wrong but left with the impression that applications using Hibernate could handle migration implicitly.
You can do either one you want. If you have a formal DevOps deployment process you would normally deploy your database schema then, and the CLI commands are how you do that with Migrations. You can run the migration in the deployment pipeline, or use the CLI to generate the upgrade scripts and run the scripts in the deployment pipeline.
See
Some apps may want to apply migrations at runtime during startup or
first run. Do this using the Migrate() method. . . .
Warning
This approach isn't for everyone. While it's great for apps with a
local database, most applications will require more robust deployment
strategy like generating SQL scripts.
Apply migrations at runtime
So while you would normally apply migrations at runtime on your private developer database, for deployment to shared environments it't often not the best choice.
So I have an EF Core project. When I need to add/migrations I issue and update command:
dotnet ef database update -v
This all works fine, if I need to update the QA, Staging, Prod database I update the connection string in my appsettings.json file and run the command.
What happens if I don't have access to production from my local machine? How do you go about updating the database to the latest migration?
If I remember working with Entity Framework (not .net core). It would try and update the database automatically when I deploy a new version of the .net application. Does this functionality still exist in .NET core?
Yes you could run
dbContext.Database.Migrate();
On startup but it is generally not a good idea to conflate database migration with your application lifecycle - best practice is to keep your application start up as fast and simple as possible because an application start failure is hard to diagnose remotely, and a migration would introduce a lot of unwelcome complexity.
The alternative is to run a migration operation as part of your deployment. It depends on what method you use to deploy but say for example you use a CI server, you will be able to run
dotnet ef database update
after copying the new code but before starting the application back up.
I am using .NET Core to build an application and I am having issues with entity framework. After creating a second migration to update changes made to my models using the "dnx ef migrations add" and the "dnx ef database update" commands, I get errors regarding the attempt to drop foreign key constraints that do not exist. It looks like entity framework is not reviewing the target database before it generates the migrations file.
To try and confirm this I created a brand new database in my development environment and updated my appsettings.json file to target the new database. I then generated another migrations file to check if it would notice the database is blank and create a migrations file to build the schema. It instead created a migrations file with the same issues of trying to drop constraints that do not exist.
Shouldn't entity framework always review the database so it can find the difference between the database schema and model classes?
Thanks
dnx commands doesn't exit any more ! It was in beta of .net core. Migrate your project to the latest dotnet core version (1.1) and use dotnet commands
To add a migration use command: dotnet ef migration add
To update: dotnet ef update
We are using Entity Framework Code First for our application. Migrations has also been enabled, and we upgrade our database through the migration scripts generated by using migrate.exe.
On a production environment, we would like to upgrade the database in-place (without downtime). In order to do this, we want to first upgrade the database, while the front-end nodes are still running an older copy of the application. Once the DB is upgraded, we would then upgrade individual application nodes one at a time.
Is this possible with Code-first and Migrations? Currently, when we try to have the older version of the application connect to a newer "migrated" version of the database, it throws the context out of sync exception (which is expected).
You could set your database initialization strategy to null to prevent your context from checking to see if there are any discrepancies
Database.SetInitializer<YourContext>(null);
I'm using Migrator.NET to manage schema changes on our production environment. Because I've been using EF code-first, all development to the database has been incremental to the code-first classes and no migrations have been applied to the project.
However, I'd like to be able to start using migrations once the project is in a production environment. As the baseline 'up' migration, I'd like to use code-first's database initializer to create the database and prime with default data. However, I'm having problems because the EF context classes and my wrapper classes for EF initializers are in .NET 4, whereas migrator .NET is using .NET 2.
When running the migrator console app, I'm getting 'This assembly is built by runtime newer than the currently loaded runtime...'
Am I expecting to much for this to work? I could use OSQL and create the SQL script on the server, but it would be nice if this worked just as it does in the development environment.
Hmm. Weird. Even if the migratordotnet binary is in .NET 2 you should be able to use it. I worked on a project where we did just this. We used EF Code First to automatically generate the schema if it didn't exist, otherwise we would run the migrations to the existing one (we started creating the migration steps while still in the dev phase).