Rails Migrations – how I’m using them

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:

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…

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.