Entity Framework Migrations Explained

Summary

In this episode of On Dot Net, host James Montemagno is joined by Brice Lambson, a member of the Entity Framework (EF) Core team, to demystify EF Core migrations. Brice explains the concept of database schema migrations as a pattern for evolving the database schema alongside application development, akin to version control for source code. He covers the importance of migrations for both everyday development and deployment, illustrating the process with practical examples. The conversation guides viewers through the creation and management of migrations, emphasizing the need for caution when modifying applied migrations. The episode concludes with insights on applying migrations in different environments and the importance of aligning database changes with team workflows.

Takeaways

• 😀 Entity Framework Core (EF Core) is a popular ORM (Object-Relational Mapper) for .NET applications that simplifies database interactions.
• 🔄 EF Core migrations are used to evolve the database schema as the application evolves, similar to how version control manages source code changes.
• 🛠 There are two main workflows in EF Core: Database First, where the database is the source of truth, and Code First, where the application code is the source of truth.
• 👥 Brice Lambson, a member of the EF Core team, emphasizes the importance of choosing the right workflow based on the team's preference and the nature of the project.
• 🚀 Migrations are not just for new developments; they are also crucial for deployment, ensuring that databases are updated without data loss when a new version of an application is released.
• 🔧 EF Core provides tools to scaffold or reverse engineer the model from an existing database, which is useful for Database First approaches.
• 📝 The process of creating migrations involves generating an 'up' method to apply changes and a 'down' method to revert them, encapsulating the changes made to the database schema.
• 👀 It's important to keep migrations in sync with the application's model to avoid conflicts and ensure a smooth deployment process.
• 🛑 The 'remove migration' command in EF Core allows developers to undo the last migration, which is helpful for correcting mistakes before they are shared with the team.
• 🔗 The 'Update Database' command applies pending migrations to the database, and it's commonly used during development to keep the local database up to date with the application's schema.
• 🔗 For production environments or server scenarios, EF Core offers the 'script-migration' command to generate a SQL script that can be reviewed and applied by DBAs as part of the deployment process.

Q & A

What is the main topic discussed in the 'On Dot Net' episode with Brice Lambson?

The main topic discussed is Entity Framework Core migrations and how they can be used to manage database schema changes over time.

How long has Brice Lambson been working on the EF Core team?

Brice Lambson has been working on the EF Core team for almost 12 years.

What is the purpose of database schema migrations in the context of application development?

Database schema migrations are used to evolve the database schema as the application evolves and requirements change, similar to version control for source code.

Why are Entity Framework Core migrations considered important for application development?

EF Core migrations are important because they allow developers to manage and track changes to the database schema in a structured way, facilitating collaboration and deployment.

What is the difference between 'database first' and 'code first' workflows in EF Core?

In 'database first', the database is the source of truth and changes are made directly to the database which then flow back into the application model. In 'code first', the application code is the source of truth and changes are made to the code which then flow into the database through migrations.

Why might a developer choose to use 'database first' approach instead of migrations?

A developer might choose 'database first' if they prefer to work directly with the database, manually crafting their database schema, or if they are using tools like SQL Server project to manage database schema changes.

What command is used in the Package Manager Console to create a new migration in EF Core?

The command used to create a new migration in EF Core is 'Add-Migration' followed by a name for the migration.

What does the 'Update-Database' command do in EF Core?

The 'Update-Database' command applies any pending migrations to the database, bringing it up to date with the current state of the application's model.

What is the significance of the 'Up' and 'Down' methods in a migration class in EF Core?

The 'Up' method in a migration class is used to apply the migration and update the database schema, while the 'Down' method is used to revert the changes made by the migration, effectively rolling back the schema to its previous state.

How can developers ensure that their local database is in sync with the latest model changes without affecting the production database?

Developers can use the 'Update-Database' command locally to apply migrations and keep their local database in sync with the latest model changes without affecting the production database.

What is the recommended approach for applying migrations in a production environment or when working with a team?

In a production environment or team setting, it is recommended to generate a SQL script using the 'script-migration' command, which can be reviewed and applied by DBAs as part of the deployment process.

Why is it not advisable to apply migrations directly to a production database that is accessed by multiple servers?

Applying migrations directly to a production database accessed by multiple servers can lead to conflicts and inconsistencies, as different servers may try to apply changes at the same time.

How can developers keep track of which migrations have been applied to a database?

EF Core maintains a special table (with a name that starts with double underscores) in the database to keep track of which migrations have been applied.

What does the 'Remove-Migration' command do in EF Core?

The 'Remove-Migration' command undoes the last migration that was added but not yet applied to the database, allowing developers to make changes to their model without affecting the migration history.

Outlines

00:00

🎥 Introduction to EF Core Migrations

James Montemagno hosts the 'On Dot Net' episode, featuring Brice Lambson, an expert on Entity Framework Core (EF Core) migrations. The episode aims to demystify EF Core migrations, a topic that is considered crucial for database schema management. Brice, a member of the EF Core team for nearly 12 years, discusses his role and the importance of migrations in evolving database schemas alongside application development, akin to version control for source code.

05:01

🛠 Understanding EF Core Migrations

The conversation delves into the practicality of EF Core migrations, contrasting two primary database development approaches: database-first, where the database is the source of truth, and code-first, where application code dictates the database schema. Brice explains the scenarios where migrations are essential, such as synchronizing schema changes among developers and preparing for application deployment with an updated database schema. The discussion also touches on the limitations of automatic schema changes in SQLite and the need for a migrations framework for more complex modifications.

10:03

🚀 Getting Started with EF Core Migrations

Brice guides viewers through the initial steps of setting up EF Core migrations. He demonstrates how to install the necessary tools using the NuGet package manager console and emphasizes the importance of creating an initial migration to define the starting point of the database schema. The process involves generating a migration class with up and down methods that represent the changes to be applied to or removed from the database, respectively.

15:05

🔍 Anatomy of an EF Core Migration

This section provides an in-depth look at the structure of an EF Core migration file. It explains the purpose of the up and down methods within the migration class and how they are used to apply or revert database schema changes. The discussion highlights the use of a timestamp in the migration filename to maintain a chronological order of migrations. Additionally, Brice explains the role of the migration's designer file and the model snapshot in tracking and applying migrations.

20:07

🔄 Modifying and Managing Migrations

Brice illustrates how to modify an existing migration by making a schema change in the application code and then creating a new migration to reflect that change. He also discusses the use of 'remove migration' to undo a migration that was not yet shared with the team, comparing it to amending a Git commit. The importance of keeping migrations in sync with the application model is emphasized, and the potential issues of editing migration files directly are highlighted.

25:08

📚 Applying Migrations and Best Practices

The episode continues with Brice applying the 'AddPostAuthor' migration to the database using the 'Update Database' command. He explains the implications of applying migrations to a shared database and the importance of considering the impact on team members and production environments. Brice also discusses the use of SQL scripts for deployment, particularly in server scenarios where multiple instances access the same database.

30:09

🌐 EF Core Migrations in Different Scenarios

Brice addresses the question of how EF Core migrations handle databases that do not exist on a server. He differentiates between client applications, where migrations can be applied at startup, and server scenarios, where a more controlled approach using SQL scripts and DBA review is recommended. The conversation wraps up with a brief mention of EF Core documentation and additional resources for further learning.

35:10

🎉 Conclusion and Resources

In the final segment, James expresses his appreciation for Brice's detailed walkthrough of EF Core migrations, which he plans to rewatch for better understanding. Brice provides a final recommendation to visit the official EF Core documentation for more in-depth information. The episode concludes with a reminder for viewers to engage with the content by asking questions, subscribing, and following the show for updates.

Keywords

💡Entity Framework Core (EF Core)

Entity Framework Core is an open-source, lightweight, and extensible version of the Entity Framework data access technology. It provides a simple yet powerful way to work with relational databases using .NET. In the video, EF Core is the central theme, as the discussion revolves around its capabilities for database migrations, which are essential for evolving the database schema as the application evolves.

💡Database Migrations

Database migrations refer to the process of managing changes to a database schema over time. In the context of the video, migrations are used to evolve the database schema as the application changes, similar to how version control is used for source code. The script discusses EF Core migrations, which are a way to apply these changes in a structured and version-controlled manner.

💡Brice Lambson

Brice Lambson is a member of the EF Core team and a guest in the video. He has extensive experience with EF Core and is brought onto the show to demystify the concept of EF Core migrations. His insights and explanations provide a deeper understanding of the topic for the viewers.

💡Reverse Engineering

In the realm of databases, reverse engineering is the process of creating a data model from an existing database schema. In the video, Brice Lambson mentions working on reverse engineering, which is a feature in EF Core that allows developers to generate a model from an existing database, which can then be used for further development or understanding of the database structure.

💡Code-First Workflow

The code-first workflow is an approach in EF Core where the application code is the source of truth, and the database schema is generated based on the code. This is in contrast to the database-first approach, where the database schema is defined first, and then the application code is generated from it. The video discusses the code-first approach as a scenario where migrations are particularly useful.

💡Model Snapshot

A model snapshot in EF Core is a representation of the current state of the model at a specific point in time. It is used by the migrations framework to understand what changes have been made since the last migration. In the video, the model snapshot is mentioned as a crucial part of the migration process, helping to track changes and generate new migrations accordingly.

💡Up and Down Methods

In the context of EF Core migrations, the 'up' and 'down' methods define the operations to apply and revert a migration, respectively. The 'up' method contains the code to apply the migration and update the database schema, while the 'down' method contains the code to revert the changes. These methods are central to the script's discussion on how migrations are structured and executed.

💡SQLite

SQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured SQL database engine. It is used in the video as an example of a database that can be managed using EF Core. The discussion includes how EF Core interacts with SQLite and the specific considerations when using it with migrations.

💡Data Annotations

Data annotations in EF Core are attributes that can be applied to model classes and properties to configure the model at design time. They provide a way to decorate model properties with metadata that EF Core can use to understand and enforce certain constraints, such as making a property required, as demonstrated in the video.

💡Onion Migration

An onion migration, though not explicitly mentioned in the script, is a concept related to migrations where each layer of the 'onion' represents a different aspect of the application that needs to be updated as part of the migration process. The video touches on the idea of applying migrations in a layered and structured manner, similar to the onion migration concept.

💡Version Control

Version control is a system that records changes to a file or set of files over time so that developers can track and manage those changes. In the video, version control is used as an analogy to explain how database migrations work. Just as version control tracks changes to source code, migrations track changes to the database schema.

Highlights

Brice Lambson from the EF Core team joins the On Dot Net podcast to demystify Entity Framework Core migrations.

EF Core is one of many options for database migrations, which are essential for evolving the database schema as the application evolves.

Database schema migrations are similar to version control for source code, allowing developers to record and share changes to the database schema.

Brice has been working on the EF Core team for almost 12 years, focusing on migrations, reverse engineering, and other core functionalities.

SQLite Dash Net automatically handles additive changes to the database schema, but migrations are necessary for more complex changes.

EF Core migrations allow developers to keep their code as the source of truth and generate database schema changes from the code.

The EF Core migration workflow is explained, including creating an initial migration and applying it to the database.

The anatomy of a migration includes an up method to apply changes and a down method to revert them, encapsulated within a migration class.

Migrations are version-controlled and can be committed, amended, or rolled back similar to Git commits.

The importance of naming migrations with descriptive names to act as commit messages for the database schema changes is discussed.

EF Core uses conventions to minimize configuration, allowing developers to write less code by following certain patterns.

The process of altering a column in SQLite requires EF Core to recreate the table due to SQLite's limitation on altering columns.

EF Core migrations can be used in team environments to keep everyone's local databases in sync with the evolving schema.

For server scenarios, EF Core recommends generating a SQL script for migrations that can be reviewed and integrated into the deployment process.

The podcast wraps up with a discussion on best practices for using EF Core migrations in different development environments.

Brice Lambson provides valuable insights and tips for new developers getting started with EF Core and database migrations.

The episode concludes with a reminder to check the official EF Core documentation for more detailed information and guidance.

Transcripts

>> Tune in to this week's On Dot Net,

where I have my good friend Brice on,

who's going to demystify

entity framework core migrations, so tune in.\

[MUSIC]

>> Hey, everyone, I'm James Montemagno and I'm back

with another On.Net episode this

time probably one of

my favorite topics of all time because I know nothing about it,

which is all about database migrations with entity framework core.

I brought none other than

my best friend in the entire world, Brice Lambson.

How's it going Brice?

>> Howdy, it's surreal being here.

I remember when this show premiered in 2016,

I've been a fan ever since. I'm honored to be on.

>> I'm super excited because everyone on

the EF core team is just like, you got to have Brice on,

you got to have Brice on because I'm like,

I don't know anything about anything.

You're on the EF core team, correct?

>> Yes.

>> Yes. How long was it?

How long have you been on the EF core

team and what all do you do there?

>> Oh, man. I've been on there almost 12 years now

and I've been working on migrations almost since the beginning.

I work on reverse engineering,

I work on a lot of cycle light stuff.

Those are the things I remember right now.

>> What would you say, now, if people are just turning in,

they're like, I'm in database migrations. I love that.

What is the pitch for EF Core in general?

Why are people using the EF Core and why is it so important?

>> Yeah, EF Core is just one of many options.

Database migrations have been around,

specifically database schema migrations

in other word migrations is very overloaded.

We're talking here about your database schema,

which is all the tables like columns,

the foreign keys, all that database stuff.

Migrate data schema migrations is

a pattern for really

evolving that schema as your application evolves,

as the requirements change.

You can think of it a lot like version control,

which is for your source code.

You record what changes you make to

your source code so you can share those with other developers.

Schema migrations are the steps to

evolve your schema as your application evolves.

They definitely weren't invented by EF,

they existed long before.

If you've ever used Ruby active record had migrations before us.

Even way back in the day I remember manually

writing little tiny bits of

sequel and checking them in the repository.

That's the pattern, it's recording the changes to the schema.

>> I have a database, I have a person,

for example, and I have a first name,

last name and I deploy that application and then I'm like,

oh, I forgot to add a middle name.

Is that the scenario that I need

a migration or is it a scenario where I'm like,

oh, actually, I put it as a string,

but it should really be an integer or something.

Are those both examples that I just listed as migrations?

>> Yeah, definitely. I think there's two big use cases.

One is for everyday development,

just like virtual control.

Like I'm working on a feature,

my teammate's working on a feature and we're

both evolving the database schema and I don't want him to

break me while I'm trying to work on

my feature and so it's just everyone being on

the same page in terms

of their local database that they're testing with.

Then you also mentioned deployment and

that's another things like, oh,

we need to ship Version 2,

all the databases are still in Version 1.

How are we going to not delete

all their data and yet update their databases?

Those are the two big scenarios.

>> Got it. Now, how come it just

doesn't magically happen for free?

Because I come from the mobile world where I

use SQLite Dash Net and I'm

just slang in Pogo objects everywhere,

adding stuff, removing stuff.

It just does it automatically, I think.

How come that just can happen?

>> Yeah. Frank Kruger is a ninja.

SQLite Dash Net,

it hides all those stuff from you.

It's really good at additive changes.

In fact, it's so good you don't even know it's doing it.

You just hand it data and it says,

oh, I need to put this data somewhere.

I'm going to create a column for you.

I'm going to create a table for you.

Additive changes, you've probably never even

encountered those database schema. It works.

It gets a little tricky when you want to

split the name column into a first name and a last name.

That SQLite Dash Net will then

create two new columns and the old one is just there.

Yeah, you need to grow up into a migrations framework.

If you're using SQLite Dash Net,

there's a really great library called Fluent Migrator,

I think is what they call it and same with

Dapper, you're not using EF.

You probably don't want to use EF just for migrations.

There's another library that encapsulates this pattern

of recording the steps to

your database and you write it all in C-sharp codes.

You don't really need to know SQL.

That's the real beauty of a migrations framework.

>> Got it. That's super cool. I've been

getting into the web world where

EF Core seems like just the de

facto as a donor developer that I'm going to use,

it's built into templates and beautiful scaffolding.

I think the very first time I was going

through an MS Learn module in the Kamro,

it was I'll create this thing and run a migration.

I was like I have no idea what's happening right now.

I clicked a button and things happened.

I was hoping that you could demystify that in a logical step.

I'm brand new, which I am,

by the way, to this.

What am I actually doing or what is

happening and how does the tooling going to help me?

>> Yeah, before we get there.

As with any tool, you need to stop and ask yourself,

is migrations even the right tool for me?

There's a lot of people who really love writing SQL,

they like to craft their database by hand.

They might have a SQL server project and they add tables to it.

It's the source of truth,

if you will, for the model.

Everything flows from the database.

You want to add something to the database,

you go change the database and then

it flows back into your application.

The SQL server project tools

have a really cool thing called schema.

Therefore, you model your table and then you say, okay,

I want to make these changes to this database

and it will go out and make those changes.

We like to call this a database

first workflow on entity framework.

If you love doing this,

if this is how you work,

migrations are for you.

>> Okay.

>> Continue writing your little SQL scripts or

using the database project deploy tools.

In fact, there's a really cool project called DB app,

which is associated with Octopus deployment,

you can use it outside of that.

All it is is a little console app that you add

your SQL scripts to and

then it can just apply those to a database.

It takes care of the tedious part of running

those one by one and making sure they run in order.

Yeah, that's the tool if that's your workflow.

>> Okay.

>> Where migrations really

shine is on the other end of the spectrum,

you want your code to be the source of truth.

You want to add a feature, the first

place you think to go is go change

my app code and change it there and so we call this code first,

although you don't have to start with the code first,

but we like to call this code first because it's

the code is the source of

truth and then everything flows from there,

whether that's you change your domain model in

your application and then you go write a migration

or you have it generated for you in the case of EF.

That's the flow there.

>> Got it. That makes a lot of sense where it's like

I see where you're coming from is like, hey,

this database is controlling the scheme

and that is the source of truth or the code,

like you said, code for database first code first make sense.

The code and that's what I'm used to is like,

here's my person in class, here's the thing.

I'm like, database, please be

what I want you to be basically instead of

the vice versa which is database you are

this and my code will react to that. Did I summarize that correct?

>> Yeah, and if your database is the source of truth,

we have something called reverse engineering or scaffolding.

You would make those changes to the database and then you just re

scaffold your model and it would

bring in all those changes for you.

That's a tool for that. But if we

want to look at what it looks like.

>> Yeah, it's all right. You want to bring

up your monitor and we'll give it a look. Cool, I see it.

>> Here's my super simple application.

It's just a console app. I'm not fancy.

EF works anywhere, you can imagine it works in.NET MAUI projects.

You are an Android app and we work on Blazor WebAssembly.

If you want to write a little SQL database

on the client side of the browser,

which is like mind blowing, you can do that.

As you mentioned, it's very popular with

server side applications if you have a web API.

A lot of times you go through.

Just a console out today just to keep things simple for this demo.

>> Okay.

>> Here I have a blog context and this is

the EF's entry point into the database and then on it.

Right here is just an if statement,

if I don't have any posts,

add some sample ones just for

the sake of having it in our database,

and then go through every post

in the database and just write them out.

>> Looks super duper simple.

That blog context,

that is, something that's important.

>> Yeah. Let's have a look at that.

>> Okay.

>> I have it over here in my model.

It is just a class that inherits from

the DB context and this is just entity framework magic.

You don't really need to know what it even does.

Then you have these things called DB sets and these map,

one to one to a table.

>> Okay.

>> Gross table.

>> DB set is like a table and then that table is

going to have columns with different items in it,

basically, like what is a post? Is that correct?

>> Yeah, and if you've ever heard the term like a unit of work,

I'm creating a new blog context is like saying,

I'm starting a unit of work.

I'm going to make some changes to the database

or I'm going to get some stuff out of the database.

You create a new one of these to go back to program,

you create a new one of these,

make the changes, and then commit

that unit of works persist everything to the database.

>> Is that what we would call a

transaction basically at that point?

>> Yeah, every time you call save changes there,

it wraps all these changes right here.

It's adding three rows to the database in a single transaction.

If it fails, you end up somewhere in the middle.

>> See, I know a little bit of the lingo,

but yes, Frank has hidden most of it from me.

I get it. Perfect.

>> Then just in here, I'm using SQL lite.

EF call works with all databases, PostgreSQL,

we work with MySQL,

SQL Server obviously,

Azure SQL, you name it.

There's lots of providers. I like SQL 8 because it's simple.

Here I'm just writing to a file called Blogs.db.

Then here I have my plain old sale,

or object, my pocker for my model.

This could flow all the way into your views if

you are writing like a client side up.

Here's a post it has an ID.

Lots of database is just use

surrogate primary keys they call them just to keep track.

Because there's no such thing as like an instance.

You can't just take

an instance out of the database and shove it in a C-sharp,

this identifies this piece of

data and it has a title and it has some content. Super simple.

>> Nice.

>> I've got my app written,

my super cool app.

I'm ready to run it. Let's see what that looks like.

>> At this point, you haven't really done

any these usual code basically.

>> Yeah. This is all just plain old.

Immediately I had an error.

>> Oh my goodness. It's ah.

But what's going on because I thought you are all about,

EF on the EF team,

how could this happen.

>> It says there's no such table posts.

I don't have a database.

I never created the database.

I wrote on my code and I went to query

it and it threw it because it couldn't find any data.

I couldn't even find the database.

Let's look at what it looks like to actually create the database.

The first step is to create a new migration.

For this we use the NuGet package manager console.

Is a little tool here, and this is an odd little thing.

You can think of it as like a console

that knows more about Visual Studio.

You can actually use those to install packages.

The first step, when you want to get started,

you need to install the tools.

>> You're bump that up for me on that little 100 down there.

>> It works.

>> Yeah keep it going a little bit more.

>> Here we go.

>> Perfect.

>> It's really big. I'm going

to use this to install the tools as an airbag.

You could also right-click on

your Solution of managing the packages.

I just put it in the console here to get used to it,

because you're going to see it here in a minute

when we start using migrations.

>> I need this, so even though it's

just like initializing the database,

I'm still creating a migration that gets an initial migration.

>> Yeah, your very first migration

is going to go from nothing to something.

You're going to create the schema as it

is right now in your account.

>> Got it, I think that was always my confusion because I'm like,

I'm not really migrating anything, but that makes sense.

You are migrating from you had nothing to this is the thing

that you want in v1. V0 to v1.

>> I'm going to install this tools package.

All it does is just add a package to my CS project.

Well, that's really big.

I think those are linked together.

I'm not going to zoom out yet, so I'm going to keep working here.

>> Okay.

>> Now I have these tools installed and they

add a few commands you don't have to use.

This is the Visual Studio way of doing it.

There's another way if you're working

in like Visual Studio or outside of Visual Studio,

like Visual Studio from Mac or of your code or if you like,

Emacs or VM or whatever.

You can do all this stuff on the console and

the way you do that is just go in that tool install.

I like to install it globally,

so that's available everywhere.

It's just a tool called.Net EF.

>> Cool.

>> This is the command line way.

If you're a console junkie and you like black and colorful text.

Then it has similar commands

to what you're going to see in a minute.

You just invoke it with.NET EF.

You get to see this cool little unicorn.

>> You can't be [inaudible] I mean, come on.

>> For sure. I actually created that.

I put it in as a joke with the team.

Let me keep it, so I was excited.

It has migrations, commands.

It has commands for working with the database or the data context.

This is a command-line way of doing it.

I'm not going to show that because I like using Visual Studio.

I like to stay in Visual Studio.

There's PowerShell command for the same thing.

Right now we're going to add a migration.

We're going to just call it InitialCreate.

Now, this is like a get republic or I have like

my first command where I add all my code.

I'm going to add all my schema as it

is now so I can start evolving it.

>> Is that initial create,

is that just a tag that you set or

is that actually a keyword that's of importance?

>> This is the name of the migration.

You can think of it as like a commit message,

and the way it comes out is it

actually becomes the class name here.

>> Interesting. I'm not

going to spoil it, you're going to do much cool stuff.

I'm not going to stop [inaudible].

>> Yeah, you see over here,

by default, it creates a migrations folder.

Then you can see the initial create there,

and it puts this big old time stamp in there.

The reason it uses the time stamp

is to help keep everything ordered correctly,

because at the end of the day, they're

just files on the file system.

But if you can see like the sequence of

changes and if your team's

working on something else and you merge in their changes,

you see when they made their change.

>> Got it. That makes sense.

>> Let's look at the anatomy of a migration.

You get this class that has an up method and it has a down method.

The up methods bring the database up to date

with this migration where your model was at, in this migration.

It has this funny little DSL,

looks like SQL,

but it's very C Sharp as well.

We're going to create a table,

so the post table has an Id,

has a Title, has Content,

it's got a PrimaryKey, that Id column.

One thing here, though

the title here says that it's knowable true.

That was like a mistake, like, oops,

I'm not ready to share this with the team.

I'll show you in a minute. We're going to get to that.

Let me finish going through the anatomy.

>> Okay, got you.

>> I getting ahead of myself, so excited.

All right, the down method

obviously if you unapply this database,

you go back to nothing and so we drop the only table we created.

>> A drop is like a deletion?

>> Yeah. It'll delete the table

and all of its data from the schema in the database.

>> These are just helper methods,

no one's calling this yet.

These are methods that you could call.

I guess you could new up

an initial create and then call those methods.

>> Interesting point. When this method right here is called,

it doesn't actually create a table.

This tells EF to generate SQL in order to create a table.

That is a very important distinction.

This is defining the script.

This isn't actually just finding

like execute this code procedurally.

It's a little language that EF uses to represent a migration.

It's abstracted away from the specific database.

Like you can see traces of,

oh you're using SQLite,

we're going to throw in an Autoincrement there.

But in general like whether you're using MySQL,

PostgreSQL server, all the migrations use the same language here.

>> Got it. Cool that makes sense.

It knew that the idea

to autoincrement that was the thing, just EF magic?

>> Pure EF magic, yeah.

You can type every little thing about your model saying this is

the primary key and I want to use this database type.

EF has just a ton of conventions.

By default, it will look for

an integer or I don't even think I was doing integer.

It just has to be a column named Id,

and that will be your primary key.

So if I wanted to call that key,

suddenly EF wouldn't know what

the primary key was and you'd have to go and tell it.

>> Got it.

>> We call it convention over configuration.

You don't want to go configure everything,

so we have these conventions and if you

follow them you can write less code.

If you don't follow them, you can tell us

what we don't know, tell EF how to do it.

>> Cool.

>> Back to the anatomy of a migration.

Underneath this little initial create with the up and down,

there's this designer file.

Peel back the curtain and look behind and see what's here.

You don't really need to know about this.

All of this is a snapshot of

your model and it's almost never used.

It's just here in case when we're generating that

SQL we need additional information and a look here.

One cool example is on SQLite.

You can't actually alter a column, they don't support that.

One of the things we have to do is we

have to rebuild the entire table,

like recreate it in a new place,

copy all the data over and delete it.

All just for a little alter column.

The alter column clearly isn't enough to do all of that,

so we'll actually peek back here and say, okay,

when we recreate this table,

it's going to need all this additional information.

This is like a last resort though.

>> Got you.

>> Because we can, we use the stuff that's right here.

>> Okay, cool. It's cool that it's there.

>> Yeah. Good to know it's there. Don't delete it.

It might be used. The other thing

we get as a model snapshot and it's exactly the same thing.

It is another snapshot of your model at this point in time.

This one has a very different purpose.

This is so that the next time you call on migration,

we know where we're coming from.

Because if you're just changing your apps model

like we don't know.

All we have is an up and down method.

This tells us create an up and down method for

the changes between the snapshot

and then when you generate a new migration,

this snapshot will be overwritten with

the next current model on the next current model.

>> Got it. What you're

saying is like this is the current snapshot in time

and then the migrations

would build up all the changes that you made do it.

>> Yeah.

>> Okay.

>> All right, so that's the anatomy of a migration.

Like I said, I don't like

that you can add

a post without a title. That doesn't feel right to me.

I want to go back and I want to make that required.

The good news is I haven't shared this migration with anyone,

so I can just go and actually delete all this stuff.

But again like if you've added two migrations you don't want to

just delete the snapshot because that it will be completely lost.

>> Got it.

>> There's another command to sort of keep all this stuff in

sync and it's removed migration.

>> This is kind of you're playing

around with it. You're a developer.

You think that you did it but actually you didn't do it.

You're like I messed up, rollback.

I don't want to go into Git and

undo everything because you don't want to

mess up all your code changes basically.

>> Yeah. I really

like thinking about version control in this context.

Like, oh I thought I was ready to

commit my changes and push and send a PR.

Whoops, I'm not quite ready,

so let me go back and sort of

amend that last commit and Git lingo.

>> Got it.

>> I'm going to undo this migration.

I want to take this one away.

I'm not ready to share this with anyone.

It's not in the way I want it to be.

Remove migration just sort of removes the last migration.

>> Okay, just like the last one in general?

>> Yeah. While keeping

the snapshot in sync and everything like that.

Of course it was my first one, so I just deleted it.

All right, let's go and make that column actually required.

I'm just going to use data annotations

here because they're simple to understand.

>> This is part of EF Core or?

>> Yeah, this is part of EF Core.

There's two ways to do things.

One is with these annotations,

the other is to override on model creating.

It's a lot more code but some people really prefer that.

Then you could say modelBuilder.entity Post.

This property, oops I forgot my parenthesis.

The Property Post.

You can see it's a lot more code.

>> Yeah.

>> The dot is required.

>> Oh, wow. Okay.

>> If you really want to write it this way you can.

One of the reasons people don't like

these annotations is that they pollute your POCOs.

It's not really a POCO anymore.

It knows more about how it's resisted.

I think required doesn't really fit that definition

because your UI layer might use this for validation.

>> Yeah, sure.

>> It's just a flavor.

There is no right or wrong way.

We just allow different ways of doing things.

>> Yeah. I've definitely seen people that I really,

really want my model to be in

a completely separate library

and it should do nothing about anything.

That's cool that there are those two options.

>> Yeah. Let's look at that one again.

All right, and now we can see that

the title column is not nullable.

You must specify one of these.

>> Got you. You needed to do it there.

You couldn't just go on and change.

You should really never change these files basically.

You shouldn't touch them.

>> I wouldn't say that. You may want to change

these but don't change them in a way

that is out of sync with your entity framework model.

You could say now it's required in my domain model but actually,

I want to allow some bad data in there.

You want to relax some constraints.

My application should never insert this data but if

some bulk update happens to

import data without null then maybe it does. I don't know.

But yeah, in general you probably don't want to edit these.

You may want to tweak them a little bit.

But not in the way that disagrees

with what you already wrote in your classes.

That's kind of the definition of insanity. Your model is not sane.

>> Got you. Cool.

>> Now I have this migration.

It's the way I want it to be.

I'm going to go ahead and actually create my database now.

I'm going to apply this migration to the database.

There's a simple command called Update Database.

If I do dash verbose,

we're going to see a bit more output here just so you can go wow.

You can see a bit more of what's going on here.

>> This is like creating it on your local machine?

>> Yeah, it's creating it actually right here in my directory.

In fact, let's look at the database here.

Here I'm using the SQLite toolbox

by Erik Jensen, a good friend of the EF team.

It's just a simple way of inspecting SQLite databases.

Here's the post table created an ID with a primary key.

It's got a title column, not nullable.

It's got a content. In here there's this other little table.

It has double underscore, so you know

it's special, don't touch it.

>> Yeah, that's super special.

Not just one underscore but two underscores.

>> Two underscores, yeah.

This is how EF keep track of which

migrations have been applied to the database.

Again, like you're working in a team environment, you pull.

You need to apply your teammates migrations to your database,

needs to keep track of which ones.

If we actually look at this data,

you can just see there's that initial create, it's been applied.

>> Oh, cool.

>> You can even keep track of what version you

used to apply it. Just for fun.

>> Nice.

>> Now when we run our app everything should work

because we have a database, has a schema.

We can actually put

data in the database. Let's go ahead and run it.

>> Got it. There's nothing that you need to do.

You don't need to call

the migration in code because you've executed it here,

so your database is up to date with the schema.

It's executed the SQL commands to generate the tables.

>> Oh yeah. Let's go back to that verbose output.

See right here, you can see the create table post.

That update database command,

what it does, is it looks for the database.

If it's not there, it will create the database if it can.

It will see which migrations have been applied.

It will generate the scripts for those migrations,

the scripts being this create table right here

and then run those against the database.

>> Got it.

>> This is very much like a developer time thing

here, like a gesture.

We'll look at other ways of getting migrations applied.

Let's run our app and see if it actually works now.

Did that work? Did it already run?

>> It already run.

>> Let's delete that database.

Let's try all that again. It shouldn't

actually have data in there.

I'm surprised. Maybe I kept one around

on accident. Update database. Now we run. There you go.

Adding sample data,

and now I was supposed to run

it and it doesn't add the sample data,

there we go the second time I "run" it,

I doesn't have the data enlisted there.

Let's look at making another change to the database here.

For this one, let's add an author,

so each blog post should have an author here.

Now I've just changed

my application code and

that's enough for any framework to know what to do.

Let's add another migration.

>> Okay.

>> We'll just call it AddPostAuthor.

Something descriptive to help me know what's going on here.

>> I saw that it autosave the file for you.

>> Yes, that's really the beauty of using

the package manager console commands

as opposed to the command line interface,

but it doesn't know anything about Visual Studio.

>> Got it.

>> You'll also notice it will pop up the file.

Is that little, little things like that,

that make it more integrated,

which is why I still prefer it.

Here we go. We're just going to add a Column,

an Author Column to

the Posts table and it's text, and on a level.

>> Yeah, and I see you've just added it right below it,

so the very first one and then it just goes down below.

Because date, times stands basically.

>> Yeah, definitely.

Again, I haven't applied this to my database,

so let's do that. Let's update database.

It will look in the database, and say okay,

I only need to apply this AddPostAuthor,

migration has already been applied.

Then if I refresh the database over here,

it should have that author column.

I expand everything again. There it is.

>> How cool.

>> Though that's not a super simple overview of

the workflow of using migrations.

Another interesting thing,

now that I've applied this,

if I actually try to remove it,

it will warn you and say,

you've already applied this to the database.

You need to think about this a little more.

because if have you share this with your teammates,

it's like rewriting Git history.

If you do a forced push,

everyone's machine is going to be out of

sync and it's going to be very hard to get it back.

Before you just reverb and change your migration,

you need to stop and think about,

how does this migration then apply to other databases.

If it has, don't remove it,

just add another migration on top

of it so that everyone can keep rolling forward.

>> Got it, so in that case,

would you then remove the author from

your code and then run another migration?

Then actually it would disappear.

It would be like create it,

add it, remove it.

But then everyone's in sync, so it's okay?

>> Yeah, definitely.

>> Interesting, okay.

>> Again, I have that version control mentality.

This is very key to me here.

I think it really helps you use Migrations correctly.

>> Now I have a question for

you and maybe I'm jumping the gun here,

but you have a database that's here in your source code, right,

that you would check in magically and to get or not in to get,

maybe you would ignore that, so everyone's running it.

What if that database doesn't exists on a server.

How does it know when you start up your app that you need to run

Migrations or do I need a VPN into

a machine and run these commands in prod?

>> Yeah, and the answer is it depends.

Think about node development.

There are thousands of databases on everyone's phone.

You can't just VPN and run. You can't just change that.

I hope you can't anyway that would be a total loss.

You can't just change their databases.

It needs to be part of an upgrade experience.

Like, they've downloaded Version two of my app,

their database is still at Version one.

You need to roll it forward,

and so in that case, where there's,

a phone accessing a local database,

it's absolutely safe to write here

during app start to apply the Migrations,

db.database.Migrate [inaudible] how you using here.

There we go.

This does basically the same thing as our update database,

and only when your app is running it will find the local database.

It will see which migrations need to be applied.

If the database isn't there,

it will create the database.

This is super handy for client development.

But if you think about this on a server

where you're scale out to 10 nodes,

all accessing the same database,

they're going to be stepping over each other's feet.

It's going to be a nightmare,

and so we really don't recommend this on

a server scenario unless you have

a single server accessing a single database.

>> Got it. That makes sense.

>> [inaudible].

>> Yeah.

>> When you are in that server scenario,

the one where we do recommend it,

is the traditional way you generate

a sequel script and there's a command for that too.

It's just called script-migration.

>> Okay.

>> This is like an artifact that you can then go and

hand Your DBAs who know everything about databases,

they can review it,

they can say, "Well actually you need

an index here, when you create this table."

They can review it. This can become

part of your deployment process.

>> Got it. That's really good, it's really nifty.

There's all of these different commands built in,

including, here's the sequel script. That's really cool.

>> Yep.

>> Nice. Anything else you want to demo through or it's covered?

>> No, I could go on forever about this stuff,

but I don't want to overload viewers.

This is merely an introduction to how do I start using migrations?

>> I think this is great because I honestly,

I feel like sometimes I can walk through the tutorial,

but I'm not actually getting the sense of

exactly why or where all these files are out.

To me, this is actually perfect.

On that note episode I'm going to

rewatch probably like 100 times is that every time I

create a new EF Code database

and I'm using anything, I'm going to go through all that.

Brice this is absolutely perfect in every regard. I love it.

>> I'm glad, and if you want to know more,

are the docs, the docs.Microsoft/ef.

There's all kinds of great docs in there about,

Well I want to use SQL Server and SQL items in my application

or what are some other tips you have for team environments?

We have these things called bundles. What's a bundle?

They were new in the episode.

All kinds of more information,

if you go and look at the docs.

>> That's awesome and we will put links

down in the show notes below

regardless of where you're at or if you're on Docs

right now or you're on YouTube, go down there.

I'm going to get all those cool fancy

extensions that Brice had as well,

so everyone can install those.

You're using Visual Studio and of course,

also the Command-line stuff too.

Brice, thank you so much for coming on and walking through this.

This is absolutely delightful.

>> Yeah, my pleasure.

>> Awesome. Thanks, everyone, for tuning in.

If you have any questions at all about anything but specifically,

probably EF Core and Database Migrations,

leave them in the comments below.

If you're over on YouTube, I have Brice,

go and check those out and comment back

as well and I'll check on them too.

If you're over on YouTube, don't forget to like

this video and ring that notification bell.

Hit subscribe so you get notified

whenever we put out new YouTube videos here.

Brice, thanks again for coming on.

Thanks everyone for tuning in and have a great day.

[MUSIC]