How to Remove Old Database Migrations in Ruby on Rails
Rails data migration should be performed in accordance with some rules, tips and notes, so that you won’t need ages to finish it. This is all the more important when you are tasked with creating a clear development environment setup, and removing old records is key. Check how we did that when we overtook one of the Ruby projects.
Recently we’ve overtaken a big project for maintenance and further development. It’s a Rails application with many models, controllers and of course lots of database migrations. There were about one hundred files in db/migrate directory. The question is: how can we setup development environment with current database structure? Running
rake db:migrate would just be a suicide. It won’t simply work, because these migrations were written long time ago and the current code and models implementation don’t fit them. Instead let’s load
schema.rb file using this command:
It will create all needed tables for models and also a special table
schema_migrations to track migrations. Selecting all rows you will see something like this:
select * from schema_migrations order by version;
So, how can we use this special table to get rid of smelly migration files?
We can just create new migration and copy all add/create statements from
rails g migration CreateStructure
The migration can look like this:
class CreateStructure < ActiveRecord::Migration
create_table "users", force: true do |t|
create_table "teams", force: true do |t|
Then we need to change it a little bit, because we don’t won’t to lose any data while deploying new migration to staging or/and production environment. Just remove
force: true option to make sure we will never lose any data by recreating tables. So let’s try to run this new migration:
== 20140705105820 CreateStructure: migrating ==================================
StandardError: An error has occurred, this and all later migrations canceled:
PG::DuplicateTable: ERROR: relation "users" already exists
Yes, well, it didn’t work, because we’ve already loaded
schema.rb and all our tables are already there. So what can we do? We can use the latest version of migration from our
schema_migrations and rename the new one:
mv db/migrate/20140705105820_create_structure.rb db/migrate/20140427083434_create_structure.rb
Finally, we can remove all migrations excluding the current one:
cd db/migrate/ && ls | grep -v '20140427083434_create_structure' | xargs rm
Now, if we run
db:migrate we won’t see any results or errors because we’ve have already migrated the database. However, if we have to setup a new environment we can run all (one) our migrations without any problems.
There is a small problem with this solution. If you have migrations which are modifying data like adding admin account or so, you need to find them manually and copy the code to our structure migration or add a new migration. The data is not included in
We just removed all migrations by adding new one with the whole structure. We can now continue hacking and adding new migrations in normal way. Above steps can be repeated any time we want. So, you can keep small number of migrations. Just be careful when you have new migrations on your local branch, but they are not deployed to staging or production yet. It won’t work. You need too rollback your local migrations until it matches staging/production and then copy
Thanks all for now. Thank you and bye :)
Let's talk about Jamstack and headless e-commerce!
Contact us and we'll warmly introduce you to the vast world of Jamstack & headless development!
More posts in this category
Multiprocessing vs Multithreading in Ruby: Which is Better?
Can multiprocessing be a good alternative to multithreading? Sure! It depends, however, on answering the following question: does my project really need multiple processes? To get...
Aug 19· 14 min read
4 Amazing Features of Rails 6.0
Rails 6.0. is finally released. We’re excited to see all the new stuff Rails 6.0 has to offer! With regular releases of the beta versions, developers had access to the upcoming...
Apr 24· 4 min read