Question

I’m considering using Ruby on Rails for my next project. Understanding the deployment of a rails website is easy enough to understand (sounds like I’ll be using Phusion Passenger)

But now I’m trying to figure out the database. I see a lot about “database migrations”, which allow me to update the database using ruby code. I also see that I’m allowed to create both an up and down variant of these migrations.

However, I can only fathom how this works cleanly in a single direction. Imagine if I suddenly say “The color column cannot be null”. So, the up will make it required and give all NULL entries a default value. But what will the down do? If you care about it being identical to how it started, you can’t just set the default values back to NULL.

This doesn’t really matter much for releases to production. That will likely just be done in a single direction (in the up direction). However, I want to use Gerrit for code reviews as well as setting up a bot to run a build before allowing check-ins…

So how could that work? From one code review to the next, the build server will check out the new set of code, and run the migrations? But when this happens, it won’t even retain the migration code from before, so how could it run the down steps? As an simpler example, I do not see how I could check out an old version of the code and “db migrate” backwards.

Answer 1

Yes, you can’t check out an old version of the code and then run a down migration from a newer version of the code. You would need to run the down migration before rolling back to the older code.

There are many, many cases where a down migration is just not practical or possible. That’s not necessarily a bad thing. It just means that you have defined a ‘point of no return’, where you won’t be able to restore your database to an earlier state.

Migrations like creating a table or adding a column are easily reversed by simply destroying that table or removing that column. However, if you are doing something more complex, such as adding default values or moving data around, then you can tell Rails that it’s not possible to reverse this migration:

def down
  raise ActiveRecord::IrreversibleMigration
end

I would recommend that Gerrit should never assume anything about the database. It should start with a fresh database each time a new version is deployed, and run db:migrate to run all your migrations. You can use gems like factory_girl to populate your app with demo data for testing purposes.