What is a Migration?

Summary

In this video, I introduce Module 5, which focuses on making our application more data-driven by adding database migrations. I explain what database migrations are, comparing them to version control systems for database structures. I discuss how migrations typically have "up" and "down" versions, allowing us to move forward and backward through database versions. I share key best practices: keeping migrations immutable once deployed, testing both up and down versions, creating backup plans, keeping migrations small and focused, and using meaningful names. I mention that we'll be putting this into practice by creating an articles table for storing metadata.

Transcript

Welcome to Module 5. In this module we'll be focusing on adding the database during our first migration and overall start making our application more data-driven so that we store some some metadata or the metadata that we just added in the last episode we're going to store that in the database so that we can update all of this information without necessarily having to do another deploy. So main focus here is getting comfortable with migrations, getting comfortable with potentially making mistakes when doing migrations but also like what do we do if our migration goes wrong right. So all of this we're going to be tackling now so that once this module is done you should be very familiar with adding migrations and also how to work with data in a Golang full stack web application. First of all what is a database migration? Well you can think of it as very similar to a version control system but for the structure of our database which comes in very handy as our applications evolve our data requirements and data structures will also evolve so it can keep track of how our requirements have changed over time and also make it easier to go back to a state for our data requirements and structures that fit our need or was working you know you might make changes that destroy things and then we want to be able to go back to the to that point in time where we didn't we didn't mess up. In practice you will often see that migration involves two parts which is the up version and the down version and I've tried to to create like a little diagram here with the with a database lifespan where we started version zero and then we apply an up migration that takes us to version one and then later in the future we apply another up version that takes us to version two. If we for any reason made a mistake here with this up migration we will apply this down migration which will take us back to version one. This is how you typically work with with migrations in in real life you always try to plan for like an out if something goes wrong. It's not required that you that you have an up version and a down version but it is really best practice it's it's really nice to have if you if you make a if you make a mistake or you mess up having this this option to go back in time it's it's very it's very beneficial. There are a few things you should try and keep in mind when working with migrations. Try and keep them immutable which means that once you have applied them and they are deployed to production you don't modify them. Of course at the time you do apply them you have the option to do the down version fix the up version then reapply it but in general you want to think of these as git commits you don't really want to change the history so you might need to just create a new migration that fixes your old migration it might be easier for you in than using the down version. So try to keep them immutable and also always test your migrations test the up version and the down version verify that the data is what you expect both going forward and and and backward and try to get into the habit of creating a backup plan. Now this is essential if you're working with production data especially in a large database you want to have let's say a database dump that is as close to as possible to the time of when you ran or when you're going to run the up version especially if you are making changes that delete data remove data. One of the things that I have learned that makes working with migrations a lot easier is to keep them small keep them focused so if you were to add let's say two new tables to the database you would you would opt for having two migrations instead of only one. This makes the the conceptual change of the migration easier to reason about it also makes it easier to roll back and the second thing is to use meaningful names so so you you name your migration based on what they do and having them small and focused also makes this naming easier and then you can better get an idea of what happens in the over the history of the the changes made to the database. In the next episode we will be putting all of this to practice where we'll be creating our articles table that will store our our metadata we will we will run the up version and the down version we will verify everything is as we expect it to be and and I think it's important to remember that if you have not done database migrations before they might seem complex especially when we are doing them at this level you might have done it them through ORMs or something similar so you're down and dirty with the with the SQL here and I think that's really beneficial because once you've done it a few times you understand what they are much more conceptually and they become just another tool that you have in your toolbox to work with your database so don't worry if they're a little bit scary you will definitely get the hang of it very very fast.