Is It a Good Idea to Purge Old Rails Migration Files

Is it a good idea to purge old Rails migration files?

They are relatively small, so I would choose to keep them, just for the record.

You should write your migrations without referencing models, or other parts of application, because they'll come back to you haunting ;)

Check out these guidelines:

http://guides.rubyonrails.org/migrations.html#using-models-in-your-migrations

Delete old migrations files in a Rails app

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.

What is the purpose of keeping all previous migration files in rails?

No - when constructing the database from scratch, you should just use the schema file, located in schema.rb. You can create a database schema from this using rake db:schema:load.

The point of keeping migrations around is that if someone checks out one version of your project, and then a month later they want to update it to the latest version, they need to know incrementally how to get from the database structure then to the database structure now - without losing any data. So they can just run the migrations between those two points, which will transform the database step-by-step into the up-to-date version.

Can I delete all migration files and start from scratch?

Migrations are used to update your database or to rollback to previous versions. Once migrations have been run in all environments, they're never looked at again (unless you're manually messing around with the schema_migrations table of course). Once all your migrations have been run, the current state of the database is in db/schema.rb (or db/structure.sql) so schema.rb is all you need to start with a fresh database.

I tend to clear out old migrations every couple months just to cut down on clutter.

As far as the version goes, you can leave it alone. As long as it represent a time in the past (such as 2017-11-29 02:35:38) and it is lower than any migrations that need to be run (which doesn't apply as you're deleting them all) then it doesn't matter what it is.

Go ahead and clear out all the migrations, they're already reflected in schema.rb and you can always dig them out of revision control if you really need them.

What's a good way to clean up my migrations in Rails?

One way to go is to take a blank database and run all the migrations. Now you've got all the template data which you can save to a yaml. The yaml plus the schema should be enough to bring the DB back without running any of your previously existing migrations.

However, other answers should mention an existing tool or gem for doing this.

Is it a good idea to collapse old rails migrations?

If you have your code under source control (you do have your code under source control, don't you?) then I'd say there's no real harm, provided you accept that rolling back schema changes is going to require either restoration of old migrations or brand new migrations. Just be sure you understand the implications and accept them before setting anything in stone.

Your current schema.rb can form the basis of a new single migration that will start a new set.

Be warned that if you have data manipulation operations in your existing migrations, static data loads, for example, and/or possible subsequent transformations, then these will need to be handled somewhere. It's something I've tripped over a few times...

Should I delete migration after rollback

You should never change your old migrations. If you realised that given column is unnecessary, write a new migration to remove it.

The reason for this is so that you can restore database schema in any point of development. If you are working in a team, the fact that you removed the migration won't change your teammates' schemas. Even more, they have no migration to revert now!

Add migration and then delete migration file

As long as you keep the schema.rb file, you are free to delete the old migration files. (But first make sure you have run the migrations before deleting them!)

You can use rake db:schema:dump to create an up to date schema file.

Any dangers of modifying an existing migration file?

As long as the migration has been ran in production, this should not cause any issues in the production environment. You could even delete it if you must (Note: not recommended if you have other team members as they will face the issue you are facing if they haven't already ran the migration locally).

To check whether a migration has been ran in a given environment you can use the following rake command:

RAILS_ENV=<environment> bundle exec rake db:migrate:status

For example, doing this in development you will get this:

RAILS_ENV=development bundle exec rake db:migrate:status
up 20190201100000 Add soups table
up 20190301100000 ********** NO FILE **********
up 20190601100000 Add supplies table
up 20190501100000 Remove food column from supplies table
up 20190601100000 Add test table
up 20190701100000 Add foo column to test
up 20190801100000 Add products table
down 20191119030000 I havent ran this

The above tells you which migrations have been ran (indicated by up) and which haven't been ran (indicated by down). It also tells you whether there is a file associated with the migration or if the file has been deleted (see the one above with no file). When you deploy your project to production, the down migrations will be ran so modifying the up migrations will not do anything.

I recommend you run the following in production to make sure the migration you are modifying has the down status.

RAILS_ENV=production bundle exec rake db:migrate:status


Related Topics



Leave a reply



Submit