EF Core/Azure SQL DB: How to run migrations without deleting current data in production-CodePudding

I have deployed a SQL database on Azure SQL database and published an API in .NET 5.0, however EF Core/Database is an area I'm lacking a little knowledge in.

My set up is that when I create a new migration, in order for the database to update I publish the app inside of Visual Studio and it automatically updates the database.

My question is: can running a new migration delete data ?

Right now I have a lot of data in the database I had to input manually and I don't want to have to input everything again because I didn't ask the "stupid question".

In other words, can you tell me how to make sure I'm not deleting the data currently in the production DB when running a new migration, especially when modifying a table and adding a new one, as well as making sure it doesn't break anything that would make my production API/database down.

I don't know how to update the database without being confused with what records will be deleted since the local DB and the production DB don't have the same data of course, and how it will get confused with the previously recorded seed data that's still in the DbContext.

As you can see I'm pretty confused about how it works in production as it is my first time having to manage a live system.

CodePudding user response：

Yes definitely. The EF core has drawback in code first approach like whenever you change anything to the respestive table it will effected data too.

Suppose as an example.

I have table Test

TestId
TestName
TestAdd
Testxyz

I have data in table like below:

TestId TestName TestAdd Testxyz
1       a         b       c
2       b         c       d  
3       d         e       f
4       e         f       g

for above table if I remove the column from entity table so that will surely remove data also, but EF core will be give you a warning in Package manager console like There might be some changes in file will affected to database kindly review the migration file.

CodePudding user response：

In some extreme cases, it may be necessary to remove all migrations and start over. This can be easily done by deleting your Migrations folder and dropping your database; at that point you can create a new initial migration, which will contain your entire current schema.

It's also possible to reset all migrations and create a single one without losing your data. This is sometimes called "squashing", and involves some manual work:

Delete your Migrations folder
Create a new migration and generate a SQL script for it
In your database, delete all rows from the migrations history table
Insert a single row into the migrations history, to record that the first migration has already been applied, since your tables are already there. The insert SQL is the last operation in the SQL script generated above.