How to stop schema.rb from being generated when running Rails Migrations

A couple of days ago I blogged about why rails migrations caused the database schema to be dumped into schema.rb. I've now found a way to stop it from happening without changing the schema_type or modifying any core Rails or Rake classes.

What I planned to do was override the db:migrate rake task to do the same as the default one bar the schema dump. My first attempt failed as it appears that rake will allow more than one task to have the same name, it runs then one after the other. The result of this was some strange migrations plus the delay due to dumping the schema!

After a little googling I found an excellent post on Matthew Bass's blog entitled Overriding existing Rake tasks. This described a similar situation and I've based my code on his advice.

I needed to delete the existing db:migrate task before adding my new one. You can't just call delete task on the Rake::Application class (there's no such method) so Matthew's suggestion was to add a delete_task method to the Rake::TaskManager module (that has access to the tasks) and then call this method before we define our new db:migrate task. The finished script is given below:

# add a delete_task method to the TaskManager and delete db:migrate
Rake::TaskManager.class_eval do
def delete_task(task_name)


# define a new db:migrate that did the same as the old one bar the schema dump
namespace :db do
desc "Migrate the database through scripts in db/migrate. Target specific version with VERSION=x, don't run db:schema:dump at the end."

task :migrate => :environment do
ActiveRecord::Migrator.migrate("db/migrate/", ENV["VERSION"] ? ENV["VERSION"].to_i : nil)
Technorati Tags: , , , , ,


Gerry Power said...

You might also want to check out this:

abeacock said...

Thank you ever so much for that tip Gerry, will most probably grab that and use it instead of my way, sees a lot neater (but a little more complex)

Stevie said...

Thanks, this helped a lot.