Matt Matero Matt Matero - 2 months ago 30
MySQL Question

Best way to handle rails migrations across staging and production severs?

I've taken over control of a rails project, however before I took the lead it was kind of just being handled by a semi-technical manager but not someone who knows rails. In this time they realized that they needed to add some tables/rows to the database, to do this they simply added them through MySQL and didn't create any migrations for them. When I first took over I added the migrations for those tables/rows so I could have them locally.

The issue is when I try to run the migrations on the staging/production severs which had the tables added manually through MySQL the migration fails(because the migrations I added to have the updated tables/rows locally crashes due them already existing). This hasn't been an issue but I would like to now add a migration for an entirely new table, but because of the old ones crashing since the tables already exist, this migration never gets ran.

To my knowledge the only way to fix this would be to drop the tables and then re-add them with the migrations I wrote. The reason I'm unsure to do that is I'd lose all the data in those tables which can't happen. There's probably a way to backup the data and reload it after I drop the tables and re-add them but I've never done that before so wouldn't know where to start. Alternatively I could manually update the DB in MySQL to add the new table I want and just keep the migrations for local but that seems really hacky and defeats the purpose of using them.

So, any ideas?


Rails uses schema_migrations table to keep track of the migrations that are already run. It has one column called version that the last run migration's number.

select * from schema_migrations;

One way is to update this table to the migration number that has the changes already applied to the database