Googlier.com News Article Search
Googlier.com Precious Metals Exchange Smart Contracts
Googlier.com Document Services
| Ruby on Rails Migration |
Originally posted on: http://staffofgeeks.net/afeng/archive/2006/09/30/92832.aspx
Recently I decided to check out the beta version of Agile Web Development with Rails book, which is targeted to be released this fall. It is very interesting that the authors also brought agility into book writing. It allows readers to provide feedback to new material during the development of the book. I am also glad to see that the migration part of the framework has become a big part of the book, even having a separate chapter dedicated to it. It uses migration instead of DDL in the entire demo application. Besides the migration, there are many significant updates to various parts of the book. But in this post, I will focus mostly on the migration tool.
The migration tool is targeting Rails applications, but it can also be useful outside the Rails world. There are some people out there already (includes us, here is my old post on it) experimenting using Rails migration as "Enterprise glue" to maintain database schemas. I hope the final release version of the book will have something on this topic.
I will outline the basics of rails migration below for those are not familiar with it.
What is Ruby on Rails Migration?
At the most simple level, it allows developers to change the database schema as the application requires it in a simple and easy manner. Instead of writing DDL scripts, you use Ruby as a DSL (domain specific language) to describe what the schema should look like when the changes are required.
Why use it?
The migration tool allows developers to upgrade or downgrade a schema version without loosing data (of course, if you drop stuff it will be lost). Sure, you can write DDL that does the same thing for you (sort of, but not really without some external tooling), but it will take a lot more effort especially when you are supporting more than one database. In theory, the migration script you write for one database should work on other databases as long as the operation is supported (currently, it supports all major databases including open source alternatives). I said in theory because not all databases behave exactly the same way for a given operation. There might be some minor differences, but that's for another post. If you need to extend or change the existing migration functionality, it is usually very easy to do so.
How does it work?
You basically write a Ruby class that inherits from ActiveRecord::Migration to describe what needs to be accomplished. There are only two methods you need to write, up and down. Up method will be called during an upgrade, and down method for downgrading.
class AddTable < ActiveRecord::Migration
In this trivial example, it creates a cars table with model, year, make, and comments columns. One interesting thing to note about model and make columns are both string type. This is not DDL we are working with. Migration uses Ruby classes to encapsulate the internal database types in order to abstract out the databases. Depending on what type of database you are using, string type might vary, but it tends to be pretty consistant across different databases. In the down method, it just does exactly the opposite, as if the script has never been run.
On the command line, if you run “rake db:migrate”, your database will be upgraded to the latest version. In this case, the cars table will be added. Each migration script will have a 3 digit number in the start of the file name which represents the schema version of the script. That same version number is also stored in the database you are using. That is how migration knows which script to run during an upgrade or downgrade. Using the example above, the file name would look something like the following:
Lets say you are currently on version four but you need to roll back to version one, you can run the following command:
rake db:migration VERSION=1
Migration supports most of the operations you would need to perform on the daily basis. But if you need to do something it does not support you can always execute DDL in your migration script.
One of the really cool things about using Ruby as a DSL is that you have the power of a real programming language to create your migration scripts. This comes in really handy when you need to create test data.
I only scratched the surface on the stuff I covered on Rails migration. I would encourage anyone that is interested to read the Rails book.