Swiftkind
Credit:

Migrating it Right: The Basics

Jul 18, 2019

Carl Shemmuel Ipanag

Developer

Now if ya’ll ever tried developing an app on Django surely you have encountered these thingies called “migrations”. Basically migrations are a bunch of scripts used to, well as the name states, “migrate” the database from one state to the next. I’m not going through an in depth explanation of how these migrations work but instead I’ll point out and illustrate the concepts of migrations as clearly as possible ‘till you understand at least just the basics for now.

You can make out plenty of illustrations about migrations. You can look at it as a chain of commands, building blocks, a set of steps, or even a highly complex building with multiple floors (migrations) that improve upon every level. Kindof like a pyramid, only that it’s upside-down. To explain my personal outlook of this, let’s take a step back and look at the structure of Django. Well not all of it of course, just the ones we need to understand the topic.

So this developer a.k.a. “Creator” made the earth(django-admin startproject earth). Well at least not it it’s fully complete state yet. Earth in it’s initial state is an empty, weightless, void without states, politics, religion and cancerous Filipinos. A Django app’s structure by default contains the following:

img1.png

Let’s look at models.py. Here we code how our database should look like. Creator then decides how animals act, how countries work, and etc. Here’s a sample of code to get the idea:

img2.png


So we now have a Human model but the thing is that we haven’t yet updated the app’s database. Creator makes a blueprint for Human but didn’t actually created it yet. A snap of his fingers and (python manage.py makemigrations) now humans can exist. But wait, man was made, yes but Creator has yet to improve earth by telling it that it should allow humans. He tosses the blueprint of man into the void (python manage.py migrate) and earth has improved by one step. Earth’s database can now accept and be able to store Einstein, Mark Zuckerberg, and Adolf Hitler.

But wait, Creator has another idea and decides to add a new feature for Human.

img3.png

Now he has improved Human. But then he needs to tell earth’s database that he improved Human so he repeats the process, makemigrations -> migrate. Now you might be thinking, why go through the hassle of updating the database everytime you make some changes? Migrations are there to compile these scripts into our database and we also need them to keep track of our database growth. But that’s as far as I know. And like I stated earlier, I won’t go through the very technical details about what migrations are in this blog. I’m pretty sure there are other blogs out there for this matter plus you can also read the documentations anytime. I’ll even provide you with a link -> https://docs.djangoproject.com/en/2.2/topics/migrations/

So to sum up the whole metaphoric story of Creation, migrations are like milestones to the growth of an app’s database, or in this case earth. And there are 3 easy steps to this:

  1. Edit your code in models.py – This is where you design the models, along with their properties and functions if any. Use your imagination.
  2. Execute “python manage.py makemigrations” – Here is where the migrations are automatically created and stored in the migrations folder and ready for the next step, which is migrate.
  3. Execute “python manage.py migrate” – The magic of migrating and updating our database happens here and you only do it once. Unless some nasty stuff happens which I will then be discussing on a future blog.