So this particular lesson is called donor entity framework migrations.
Operations are never named for this particular part.
Could be called How to get out of trouble with your migrations.
So what we have at the moment I'll just open my terminal and let's just take a look at I'll just clear
the screen and let's just take a look at the dot net.
F help.
And this gives us a list of commands that we can use Begob commands related to the database commands
related to the context and commands related to migrations.
So we can get contextual help so I'll say migrations donning of migrations bash age.
And this gives me all of the commands available related to migrations.
Now we've used the dot net adds to add a new migration before.
We've also got one to list available migrations.
We've got an option to remove the last migration and we can only use this one if we have not yet applied
the last migration by using a database updates.
Now we haven't used database a day yet to apply the integration that we've just created.
So that means this is an option that we can use and if we just take a look at our migration so just
to adopt their EAF migrations list.
And this just provides the migrations that we have created.
Now it doesn't tell us which ones apply to our database and if we wanted to get that information that
information is actually stored in our database itself.
So if I take a look a sequel browser for dbe lights I can see my if migrations history and I can see
that I've only applied in this particular database the first two and we haven't yet applied this extended
user class.
Now we know at this stage we don't want to keep this particular migration because this is not what we're
looking for for our database schema.
We want different referential action.
So what we would typically do in this case after we've checked the migration we would use the dot net
if migrations and just remove.
And this is going to remove the latest migration.
So we'll use this just to remove that particular migration.
And it removes the migration and it reverts to the model snapshots.
And remember that.
Arm in arm migrations folder we've got a data context model snapshots So it makes a change into here
and now we're left with just two migrations.
And that's fine.
That's easy.
There's no problem doing that.
But there are some scenarios where you can get into a little bit of trouble with migrations.
And I'll give you an example of this and I'll just go back to what we had before and I'll just read
add this migration.
Now you don't have to follow along with this part because I'm going to break a few things and just demonstrate
how you can get out of a particular problem but you might want to bookmark this particular section because
if you do find yourself running into issues with your own migrations then please do come back and check
the steps to recover from this.
So I'm going to add this migration back in.
And I'm back to where I was before but this time I'm going to apply this migration so I'm going to say
don't know if database.
Updates and this is langon to apply that particular migration.
Now there's nothing wrong with this migration so this works.
That's absolutely fine.
The only problem is that I don't want this migration I don't want this apply to my schema.
But it has been applied and if I go back to sequal light and I refresh now we see our migration added
to our migration history.
And I can take a look at my users in my user class has now been extended with all of the different properties
that we've added.
And we've also got a table for photos.
But the problem is I don't want this I need to change this now and we don't want to go in modifying
our database directly when we're using migrations.
We want to stick with this system that we're using and we make scheme changes to our database by using
migrations and then applying them to our database.
This means we can we can take our projects or we can upload it to get her we can clone it somewhere
else and we can get our database into exactly the same position it is now with it's the same schema.
But if we're going manually changing things then we lose that ability.
So the question is now how do I recover from this.
Because if I try and if I try and use the I don't know if migrations remove.
I'm going to get an error and it's going to tell me the reason the extended user class has already been
applied to the database and it tells us to revert it and try again.
So we do have options for this because in our migration.
In fact take a look at this.
And we've got our methods and we also have a.
Down method.
And if we go back to a previous migration then this down method is called and it drops the table and
it drops all of the columns that are being created.
So let's take a look at attempting to go back to an earlier migration.
Now what we can do is we can specify the migration we want to use when we do a Doctor e.f. database
updates.
And if we are useless added user entity then the theory goes that when we use when we do a donor if
database update and use this one then this is the migration that supply than our databases schema is
changed and deep down method is called and removes those columns in that table.
So let's give this ago and I'll say Donna if database updates and I'll say added a user entity and I'll
press return.
And boom it fails.
And what we get as the error is sequel it does not support this migration operation and it tells us
the operation has got an issue with the drop column and it gives us a link to get more information.
And in our down method we have several dropped column operations.
We didn't get an issue with the drop table low.
And let's take a look at the reasons for why this particular database operation failed and it's all
down to sequal lights.
If core database provider limitations now Microsoft say most of these limitations are a result of limitations
in the underlying sequal like database engine and I'm not specific to entity framework.
But there are limitations.
And let's take a look at what these are.
Now we have a number of supported operations and we have a number of not supported operations.
And if we take a look down at.
Be not supported.
The one that we failed on here was the drop column.
This is not supported in sequal light and we have a lot of limitations though.
There's a lot of x's in here now they do suggest a workaround in here but I don't like this especially
manually writing code in our migrations to perform a table rebuild.
I much prefer the migrations to be created by entity framework so it's easy to recover from and manually
writing code is not something we're going to look at to recover from a problem on this particular cause.
So what can we do then if we know that we can't revert back to a previous migration.
We know look we can't remove the last migration because it's already already been applied.
What exactly can we do now in a most efficient way to recover from this is to drop the database remove
the last migration because without a database there is no migrations applied so we would be able to
remove the last migration and then we can recreate our database by using a dot net database update.
Now there is a downside to this and the downside to this is that our database is going to be cleared
out of all its all of its data.
And what we get back is the schema.
But that's not really a problem in development because first of all we've only got a couple of randomly
created users that we have manually created ourselves.
Secondly there's a much better way of getting data into our database that we're going to look at soon
which is seeding data into our database and once we've got the seeding then we can drop and recreate
our database as much as we like.
So what would be first of all.
And I'll just do this now is do a dog net f database drop and I'm going to get a warning saying are
you sure you want to be this and I'm going to say yes and it drops the database.
Now this doesn't touch my migrations my migrations are still available.
But what I can do now is use one of the earlier commands and I'll say don't know if migrations remove
and this will now.
This will now allow me to remove my last migration.
And now when back to two migrations.
And if I now recreate my database by doing a dot net if they trace updates this is going to recreate
my database and apply leads to migrations to this database so we get our scheme back to where we were
before we applied this extended user class.
And this has now been done and if I go and take a look at my database and I only to open this again
because it's been deleted and recreate it so I'll just select this one and if I take a look at my user's
table this is back to how it was before.
We've just got the four columns in here no photos table and my migrations history is just these two
migrations apply to it.
So this is how we get out of problems with migrations in entity framework.
I know it's entirely possible to run into issues with migrations it doesn't take much to cause an issue.
If you went back for example to your User class and you started renaming these columns then there's
going to be a mismatch between your models and your database and that's going to cause your problem
because you've already applied this schema to the database so there might be occasions where you need
to come in and do some of these operations.
So like I say it's not a disaster.
If you do get into a bit of a mess with migrations there is there is a way to recover from this.
But what we're going to look at next is is how we can configure insitu framework and tell it about our
relationship between our user class and our photo class and how we can get entity framework to create
our schema or our migration how we want it to be created and we'll take a look at that next.