I hadn't heard of the idea of migrations until I started using Rails.
They are something that make so much sense once they make sense.
They aren't hard to grasp but if you are new to Rails or only have to deal with Rails on an incredibly irregular basis they can be very daunting.
I want to try and explain what migrations are for beginners.
What Are Migrations
Migrations are a set of commands that Rails will run through when it is setting up or changing the database for your project.
These commands will help to shape the database.
Why Are Migrations Good
There are a few reasons why migrations are good.
- The language they use is easier than SQL
- The changes can be version controlled
- The changes can be rolled back
Migrations use a Ruby Domain Specific Language (dsl), which is easier to learn and write than it is writing SQL. The other benefit of this dsl is that it acts as an abstraction so you don't need to care about what your database is when you write your migrations. This means that if someone decides Postgres is better than MySQL for a project, your migrations won't have to change.
Unlike when you just edit a database, these migrations are code that gets saved with the rest of your project, which means they can be easily version controlled and shared with everyone else on your team. If you have ever had to edit a database and then remember to tell everyone to make the same edit then you will know how great this is! If you are not using version control you should take a minute to read why I think developers should be using version control.
Migrations can be rolled back, this means that you can undo what you did. This is a great safety mechanism and means you don't have to worry about permanent damage being done.
How to use Migrations
The easiest way to write migrations is to get Rails to do it for you.
We can tell rails we want to create a table called bobs with the following line
rails generate migration createBobs name:string
This will create a table called
bobs with one column called
name that will hold stuff that is a string.
That seems like magic – it is magic!
Rails knew we wanted to create a new table because we used the word
create, it also knew we wanted to call the table bobs because we said
Now lets say we want to then add another column to this bobs table. We could go back and edit the file that was created when we did that first creation, but that would be bad because Rails will think it has already ran that migration and won't run it again for other people.
What we should do is just create a new migration!
rails generate migration addColourToBobs colour:string
In this migration we are saying we want to add a column called Colour to the table called bobs.
For reference here is the contents of the file we made when we created that first migration;
class CreateBobs < ActiveRecord::Migration def change create_table :bobs do |t| t.string :name end end end
Hopefully this isn't too daunting and shows how simple this dsl is compared to writing SQL.
Here is the next migration we created;
class AddColourToBobs < ActiveRecord::Migration def change add_column :bobs, :colour, :string end end
In both of these you will see some similarities.
- The class name is just what we called our migration.
- The class inherits from ActiveRecord::Migration – This isn't important for us but Rails needs it.
- The method change means that when we are running the migration it knows to do one thing, and if we are rolling back the migration it knows to the do opposite (so if we are doing add_column the opposite would be to remove_column, Rails handles all this for us)