22

Is it permissible to delete (or archive) old migration files in a Rails app if the schema is stable?

My migrations are numerous and I suspect there may be some problem in there somewhere, because I occasionally have problems migrating the database on Heroku.

niftygrifty
  • 3,452
  • 2
  • 28
  • 49
  • 2
    possible duplicate of [Is it a good idea to purge old Rails migration files?](http://stackoverflow.com/questions/4248682/is-it-a-good-idea-to-purge-old-rails-migration-files) – brainimus Sep 22 '15 at 19:01

3 Answers3

40

You don't need to keep around your old migration files in a Rails app, because your database schema should be captured either in schema.rb or an equivalent SQL file that can be used to regenerate your schema.

Migrations are not the authoritative source for your database schema. That role falls to either db/schema.rb or an SQL file which Active Record generates by examining the database. They are not designed to be edited, they just represent the current state of the database.

There is no need (and it is error prone) to deploy a new instance of an app by replaying the entire migration history. It is much simpler and faster to just load into the database a description of the current schema, which is in schema.rb or the SQL file.
This file should be versioned and kept in source control.

To set up automatic schema.rb generation, modify config/application.rb by the config.active_record.schema_format setting, which may be :ruby or :sql. If :ruby is selected then the schema is stored in db/schema.rb. If :sql is selected, the schema is dumped out in native SQL format of your database.

Unheilig
  • 16,196
  • 193
  • 68
  • 98
Zack Xu
  • 11,505
  • 9
  • 70
  • 78
  • 9
    This is absolutely correct. One caveat: migrations can be used to affect the _content_ of the database, rather than the _structure_. For example you might have SQL that transforms data (perhaps normalizing, converting to lower- or upper-case, etc.). Another use is some cleanup task (delete old records, correct an earlier logic error in the creation of data, etc.). Finally, stuff that should be done in `seeds.db` is sometimes done in migrations. Whether this use of migrations is *correct* is another question -- just noting that you should be careful. – Tom Harrison Mar 27 '15 at 17:01
  • What should be done with old migration files? It doesn't feel right simply deleting them. – user12121234 Oct 06 '15 at 21:27
  • 1
    Disagree with @TomHarrisonJr above only in that these things should "sometimes be done in migrations" - those sorts of SQL constraints, triggers, stored procedures, etc, should not be relied upon from migration files. Instead, the `config.active_record.schema_format` should be `:sql`, _OR_, override the `rake:db:setup` task to run subsequent SQL commands which define these sort of things (that active record / schema.rb can not). I do agree with everything else said :). – Todd Aug 08 '16 at 14:17
5

You can delete your old migrations. After you have done this, when you are setting up your app you will need to run: 

rake db:schema:load

Instead of:

rake db:migrate
Jeremy Lynch
  • 6,780
  • 3
  • 52
  • 63
1

here is what I did, I found the last version migrated on production ActiveRecord::SchemaMigration.last.version and deleted all the migrations before that in my source code.

not the best way but I did find db/migrate -type f, copied the list of files before the last version and pbpaste | rm (macos).

localhostdotdev
  • 1,795
  • 16
  • 21