The Wrong Migration

Imagine you are working on your first job, you make a mistake. Yes, it is acceptable. The team coordinates swiftly to help rectify your mistake.

Imagine you are 10+ years experienced senior engineer working on the most critical project of your company, you make the same mistake. Yes, it is still acceptable. The team again coordinates swiftly to help rectify your mistake.

A person who never made a mistake never tried anything new.
--Albert Einstein

Microsoft's open-source step has attracted more developers into the .NET Core community. Enterprise adoptions are also improving. Learning new things is one of the important aspects for developers to stay in the current trend.

And the courage to learn new things and the passion for learning them will eventually lead us to success. Of course, success is not achieved overnight. Making mistakes is one of the stepping stones to reach success.

Using dotnet-cli commands might look plain and straightforward. With the help of ef core additions, the database migrations have become easier compared to the legacy way of creating migrations.

To create a new migration: 🆕

dotnet ef migrations add <Migration-Name>

To update the migration to the database: 🚀

dotnet ef database update

To remove the wrong migration: ⛔

dotnet ef database remove

Seems the above commands look simple and straightforward. So the biggest question in your mind, "Why did I even create this article if applying migrations to the database is so simple?"

Here is the catch. Working on large-scale projects with multiple teams is different.

After updating the database, we cannot use the dotnet ef database remove command to remove the migration since it is already applied. 😫

If you are working independently on your project or learning from a tutorial, simply you can add an altering migration file or even drop the database delete the migration files, and start from scratch.

But do you really know how to handle the wrong migrations situation when working in teams or in your day job?

The purpose of the article is catered to handle this situation.

Situation: 💻

• You have included a column blog_description with max_length(100) and created a migration file.
• You applied the migration in your local database and pushed the code for review.
• The reviewer says, "Hmmm, I want you to change the column max_length(100) to max_length(255)"

Possible problems you might face include, 🙄

1. Need to modify your local development database. (Other environments if any exists)
2. Notify your team members working on the same branch. (For whatsoever reasons)
3. Have a track of other team's migrations changes for the same or the related entities.

The easiest workaround for this situation is submitting another migration altering the max_length of the column blog_description. But this is not the right way to do it.

In this situation possibly you have not done a mistake but you have got an opportunity to learn how to manage this situation.

Resolution: ✅

• First, pull the code from the master branch to get the latest good migrations if any committed by other teams.

• Verify whether changes exist in the same or related entity. If any exists, contact the respective developer or team to arrive at a consensus about the entity.

• Update the database with the latest good migration pulled from the master branch.
  

dotnet ef database update <Last-Good-Migration>

• Remove the redundant migration you have added.

dotnet ef database remove

By applying the latest migrations to the database to the simply indicates that the latest one added by you is redundant or defunct. Now once you run the remove command, the ef core cli removes the "wrong" migration added by you.

Handling these types of situations in the workplace is an art. It can be learned only by the virtue of experience.

Finally, you might ask me, "Hey, what about the guy who was working on the same branch?" 😂

"Well, tell him not to 😈"

Learn More Here