CODEWITHSUNDEEP
entity-frameworkasp.net-core-2.0entity-framework-migrations
johnny
johnny

Reputation: 19745

How do I remove a column in a database with a migration using ASP.NET Core 2?

I used database first and followed this SO question, changed a class and did,

add-migration -context myContext AddNewClassProperty
update-database -context myContext

and it worked fine.

But what if I want to remove a column(s) from the database? Later in development, I determined there should be a new class and a removal of properties from another class.

When I built my Project the errors in my dbContext class manifested because I had removed the properties and thus the modelBuilder.Entity method could not find class members. That makes sense.

What I don't know then is how I make the migration. I tried to add a new migration, but I get same failure.

How do I do the migration from the PMC? It is true I am going back and forth with database and code first. Perhaps that is causing me woe now.

Upvotes: 0

Views: 3450

Answers (2)

Iman Najjari
Iman Najjari

Reputation: 1

You can Ignore create filed in DatabaseContext class and OnModelCreating Method like this:

modelBuilder.Entity<XXX>(b =>
        {           
               b.Ignore(e => e.Email)                
                .Ignore(e => e.PhoneNumber)
        });

Upvotes: 0

Chris Pratt
Chris Pratt

Reputation: 239430

EF Core has a new way of handling migrations and monitoring database state. This has both positive and negative consequences. On the positive side, EF Core no longer requires full control over the database. You can mix and match tables that are code first and tables that are database first or that EF doesn't even know or care about, for that matter.

However, the result of this, is that unless EF was actually responsible for creating the table, it cannot manipulate it. The class that EF uses to monitor state won't have any information about these tables, and therefore cannot manipulate them.

Whichever way you go, I would say pick just one way and go forward with that. If you want to do code first, then do code first. Let EF manage the state and generate migrations, and don't ever touch the database directly. If you want to handle database schema changes, then do so, and don't mess with EF migrations. Trying to mix and match is going to get your POCOs and database all out of sync and lead to problems like what you're experiencing.

Upvotes: 3

Related Questions