Aston J

Rails Migrations – how I’m using them

Posted on: April 7th, 2012 by AstonJ 3 Comments

I’m fairly certain I am using them a little unconventionally, and just wondered – am I alone? Before going on I will add that I’m able to use them this way because a) the app is still in development, and b) I am the only developer.

Given I started on the app at the beginning of this year and have worked on it an hour or two a day (give or take a few weeks here and there!) since, notice anything unusual?

That’s right – they are mostly migrations for creating tables. But how do I modify my tables/schema?

Easy, (depending on the migration) I just open it, change it, save it. Then run:

rake db:migrate VERSION=0
rake db:migrate
rake db:populate

If the migration contains indexes that I need to change (or anything more complex that the Rails ‘change’ method can’t handle) then I just do the edit after running rake db:migrate VERSION=0.

In my rake db:populate file, I clear out tables before refilling them with the data I need to work with, eg:

# encoding: utf-8
# lib/tasks/populate.rake

namespace :db do
  desc "Erase and repopulate"
  task :populate => :environment do
    User.delete_all
    User.create do |user|
      user.email = "email@example.com"
      user.name = "Me"
      user.password = "secret"
      user.password_confirmation = "secret"
    end
  end
end

But why?

I just feel it is tidier, and easier to work with. Whenever I want to see what my table consists of I go straight to the migration, instead of the schema file (although not always – depends if I know I want to change something or not) and of course I get a fresh DB with all my defaults. Also, I think from simplicity comes a certain degree of safety – but then I am an overcautious person.

To date I haven’t found any negatives doing it this way – but then this is my first Rails app… maybe you can find a cause for concern that I may have overlooked? Or am I not alone in how I’m using them…

Tags: ,
  • RafaƂ Lisowski

    Hi,
    You are not alone! ;)
    I’m doing something similiar. I just edit migration and recreate database with rake db:migrate:reset and rake db:seed. When app goes to test mode (some people start using it) I start making incremental migrations. Of course you cannot do that when someone else is working with you.

    Regards

    P.S. nice blog

    • AstonJ

      Thanks for the reply and kind comments Rafat… it’s good to hear that I’m not the only one using migrations this way – and totally agree, once the app goes live and/or you get additional devs it’s probably best to use them the traditional way :)

  • http://metalelf0.github.com Andrea Schiavini

    Good approach, really clean and simple, but what happens when you release the app in production and you start making changes? E.g., you need to add a column to a previously created table? You can’t drop and recreate all tables each time. I prefer to release early on the same production environment (so I don’t have the release-day thrill), and this leads me to have a lot of “add_columns” migrations. Still it’s good to drop and recreate the whole database in development environment, to verify the integrity of the migrations.