Editing Existing Rails Migrations Is a Good Idea

Editing Existing Rails Migrations is a good idea?

If you are working with a team and you committed the migration then NO.

If it is only on your local environment then just create a new migration fixing what you need. You can drop tables\columns and do what you need.

Since you clean the db and reset it, then everyone will be doing the same or they will have issues if they try to migrate.

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

Can i edit migrate file and run migration?

Generally, the easiest thing is to just add a new migration to add your new column.

However, if your migration hasn't been run yet, you can certainly edit it, and then run it.

Also, if you have already run the migration, you can do a rake db:rollback, and then edit your migration, and then run it again. (I would only do this if the migration has only run in development mode and hasn't been pushed to production.)

In terms of specifying which migration you want to roll back, migrations are applied, and also rolled back, in chronological order. If you want to rollback the 3rd last migration you did, then you have to roll back the last one you did, then the second last one, then the 3rd last one. So, in that sense, you can't specify a specific migration to rollback. You have to specify a migration to "roll back to" - ie, roll back all migrations that happened since that migration.

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...

How do I edit an old Rails migration to add a reference?

You could probably solve this by adding a new index in a new migration.

In general, rolling back migrations to alter them leads to all sorts of problems. What happens with the data in these tables? And so on.

I suggest you make a new migration: rails g migration add_book_reference_on_series

Then edit it like so:

add_reference :series, :book, index: true

I hope this helps.

Best,

Change existing migration or generate new one?

This is a common problem for Rails programmers who actively develop an app for some length of time. The practice my group follows is that when we are convinced we're at a point that we'll never rollback to migration #X, we'll rollback the recent migrations we intent to keep, copy the generated db/schema.rb as our new "initial migration" and then just keep the newer ones after the initial. This will spare you from those deprecation warnings and will lighten up your codebase and repository as well.

Hope this helps.

Rails: I update migration file then run db:migrate, but my schema isn't updating

http://guides.rubyonrails.org/migrations.html#changing-existing-migrations

Occasionally you will make a mistake when writing a migration. If you have already run the migration then you cannot just edit the migration and run the migration again: Rails thinks it has already run the migration and so will do nothing when you run rake db:migrate. You must rollback the migration (for example with rake db:rollback), edit your migration and then run rake db:migrate to run the corrected version.

editing already run migrations

If I changed my mind about something regarding the migration, could I
just edit the migration and run rake db:migrate again?

You have to follow these steps

1. Do rake db:rollback OR rake db:migrate:down

2. Edit your changes and

3. Do rake db:migrate again.

This will let your changes reflect in the DB

If you already have some data in the DB and worried about losing it,then i would suggest you
to create another migration file which will reflect the changes in the DB with out losing of data

---

Related Topics