Migrations

Entity Framework Core Migrations 🚀

The Story of Your Database’s Time Machine

Imagine you have a LEGO castle. Every day, you want to add new towers, move walls, or change windows. But here’s the problem—you can’t just tear it all down and rebuild from scratch every time!

EF Core Migrations are like a magical time machine for your database. They keep a journal of every change you make, so you can:

• Add new rooms (tables) without losing your furniture (data)
• Rearrange things safely
• Go back in time if something goes wrong!

🏗️ Two Ways to Build: Code First vs Database First

Think of building a house. You can either:

1. Draw the blueprints FIRST, then build (Code First)
2. Look at an existing house and create blueprints from it (Database First)

🎨 Code First Approach

What is it? You write C# classes (your blueprints), and EF Core creates the database tables for you!

Simple Example: Imagine you want to store information about your pets.

// Your C# class (the blueprint)
public class Pet
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int Age { get; set; }
}

What happens:

• You write this class
• EF Core reads it
• EF Core creates a “Pets” table with columns: Id, Name, Age

Real Life Analogy: You tell a builder: “I want a room with a bed, a window, and a door.” The builder creates exactly that room for you!

graph TD
    A["📝 Write C# Classes"] --> B["🔧 Create Migration"]
    B --> C["📦 Apply Migration"]
    C --> D["🗄️ Database Created!"]

When to use Code First:

• ✅ Starting a brand new project
• ✅ You prefer writing code over using database tools
• ✅ You want version control for your database changes

🔍 Database First Approach

What is it? You already have a database, and EF Core creates C# classes that match it!

Simple Example: Your database already has a “Students” table with columns: StudentId, FirstName, LastName.

EF Core will create:

// EF Core generates this for you!
public class Student
{
    public int StudentId { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

Real Life Analogy: You have an existing LEGO castle. You take photos and draw blueprints of what’s already there, so you can understand it and modify it!

graph TD
    A["🗄️ Existing Database"] --> B["🔧 Scaffold Command"]
    B --> C["📝 C# Classes Created"]
    C --> D["✨ Ready to Use!"]

When to use Database First:

• ✅ Working with an existing database
• ✅ Database was designed by someone else
• ✅ You need to quickly connect to a legacy system

📝 Creating Migrations

What is a Migration? A migration is like a diary entry that says: “Today, I made these changes to the database.”

Think of it like this:

• Monday: Added a “Pets” table ➡️ Migration #1
• Wednesday: Added “Color” column to Pets ➡️ Migration #2
• Friday: Removed “Age” column from Pets ➡️ Migration #3

Each migration remembers EXACTLY what changed!

The Magic Command:

dotnet ef migrations add YourMigrationName

Real Example:

dotnet ef migrations add AddPetsTable

What happens behind the scenes:

graph TD
    A["🔍 EF Looks at Your Classes"] --> B["📊 Compares to Database"]
    B --> C["📝 Creates Migration File"]
    C --> D["✅ Changes Recorded!"]

What you get: A new file with two important methods:

• Up() - How to make the change
• Down() - How to undo the change

public partial class AddPetsTable : Migration
{
    protected override void Up(
        MigrationBuilder migrationBuilder)
    {
        migrationBuilder.CreateTable(
            name: "Pets",
            columns: table => new
            {
                Id = table.Column<int>(),
                Name = table.Column<string>()
            });
    }

    protected override void Down(
        MigrationBuilder migrationBuilder)
    {
        migrationBuilder.DropTable(
            name: "Pets");
    }
}

Naming Tips:

• ✅ AddPetsTable (clear!)
• ✅ AddEmailToUsers (specific!)
• ❌ Update1 (confusing!)
• ❌ Changes (what changes?!)

🚀 Applying Migrations

What does “applying” mean? It means actually MAKING the changes to your database!

Creating a migration = Writing a recipe Applying a migration = Cooking the food!

The Magic Command:

dotnet ef database update

What happens:

graph TD
    A["📋 Read All Migrations"] --> B[🔍 Check What's Applied]
    B --> C["⚡ Run New Migrations"]
    C --> D["🎉 Database Updated!"]

EF Core is SMART! It keeps track of which migrations are already applied in a special table called __EFMigrationsHistory. So if you run the command twice, it won’t repeat anything!

Going Back in Time: Made a mistake? You can roll back!

dotnet ef database update PreviousMigrationName

Example:

# Applied these migrations:
# 1. InitialCreate
# 2. AddPetsTable
# 3. AddColorToPets (oops, mistake!)

# Go back to AddPetsTable
dotnet ef database update AddPetsTable

🛠️ Migrations CLI (Command Line Interface)

The CLI is your remote control for migrations. Here are all the buttons:

Essential Commands

Common Scenarios

🆕 Starting Fresh:

dotnet ef migrations add InitialCreate
dotnet ef database update

➕ Adding a New Feature:

# Changed your C# classes? Create a migration!
dotnet ef migrations add AddNewFeature
dotnet ef database update

🔙 Oops, Made a Mistake:

# If migration NOT applied yet:
dotnet ef migrations remove

# If migration IS applied:
dotnet ef database update PreviousMigration
dotnet ef migrations remove

📜 Generate SQL Script:

dotnet ef migrations script

This gives you the SQL commands without running them—great for production!

🎯 Targeting a Specific Migration:

# Apply up to a specific migration
dotnet ef database update TargetMigration

# Generate script from one to another
dotnet ef migrations script From To

🎮 Quick Reference Card

graph TD
    subgraph "Your Workflow"
        A["1️⃣ Change C# Classes"] --> B["2️⃣ Add Migration"]
        B --> C["3️⃣ Review Migration"]
        C --> D["4️⃣ Update Database"]
    end

The Complete Flow

1. Make changes to your C# model classes
2. Create migration with dotnet ef migrations add
3. Review the generated migration file
4. Apply changes with dotnet ef database update
5. Commit everything to source control!

💡 Pro Tips

🌟 Always Name Migrations Clearly Future you will thank present you!

🌟 Review Before Applying Check the generated migration file—make sure it does what you expect.

🌟 One Change = One Migration Don’t bundle unrelated changes. Keep migrations focused.

🌟 Never Edit Applied Migrations Once a migration is in the database, create a new one instead.

🌟 Use Scripts for Production Generate SQL scripts instead of running migrations directly on production databases.

🎉 You Did It!

You now understand:

• ✅ Code First - Write classes, database follows
• ✅ Database First - Database exists, classes follow
• ✅ Creating Migrations - Capture your changes
• ✅ Applying Migrations - Make changes real
• ✅ CLI Commands - Your migration remote control

Migrations are your database’s best friend. They keep everything safe, organized, and reversible. No more fear of making changes!

Remember: Every great app started with its first migration. Now go build something amazing! 🚀