Rebase Rails Migrations in a Long Running Project

Rebase Rails migrations in a long running project

In general, you don't need to clean up old migrations. If you're running db:migrate from scratch (no existing db), Rails uses db/schema.rb to create the tables instead of running every migration. Otherwise, it only runs the migrations required to upgrade from the current schema to the latest.

If you still want to combine migrations up to a given point into a single one, you could try to:

• migrate from scratch up to the targeted schema using rake db:migrate VERSION=xxx
• dump the schema using rake db:schema:dump
• remove the migrations from the beginning up to version xxx and create a single new migration using the contents of db/schema.rb (put create_table and add_index statements into the self.up method of the new migration).

Make sure to choose one of the old migration version numbers for your aggregated new migration; otherwise, Rails would try to apply that migration on your production server (which would wipe your existing data, since the create_table statements use :force⇒true).

Anyway, I wouldn't recommend to do this since Rails usually handles migrations well itself. But if you still want to, make sure to double check everything and try locally first before you risk data loss on your production server.

rails: any way to run ONLY the NEXT migration (of several new migrations), do manual stuff, then run the rest of the migrations?

rake db:migrate:up VERSION=X

# do your stuff

rake db:migrate

Source: Migrations-Guide

How to rollback to beginning and recreate/rebuild new migrations

Your schema.rb file should contain the actual schema from your database. You could use it as a starting point to create you migrations. You could create a new migration for each table with the :force => true parameter to overwrite the old table. Afterwards you could just delete the old migrations (you would probably also need to delete their entries from schema_migrations table).

Another options would be just updating the old migrations to match your current schema.

Way to flatten Rails migrations?

This is what the db/schema.rb file is for. If you've only got structural changes in your migrations you will be able to run rake db:schema:load rather than running rake db:migrate to get the absolute structure for your tables.

Aggregate migrations in Rails

It is possible, but probably not a good idea to aggregate the migrations!

Maybe ask:

• Why do you want to do this?
• How often do you really need to migrate all the way to VERSION=0 and then back up again?
• Is something really broken? (if not, then don't fix it)

I've had the same problem once.. I ended up just re-ordering my migrations, because changes in the schema caused it to not correctly migrate up/down anymore. I would be hesitant to do that again.

If you have migrations which just add fields or indexes, then maybe you can combine them with the main migration for the model -- but beware that you can't reproduce old situations anymore, e.g. older DB-dumps may not be compatible with what migration number they should be compatible with -- that is probably the biggest argument against aggregating...

Technically, you can dump the schema and then load it directly - that is one way:

rake db:schema:dump

then create a single new migration with the contents of the schema dump file db/schema.rb

Here are some similar questions:

• Rebase Rails migrations in a long running project

• Deleting/"Rebasing" rails migrations

• Way to "flatten" Rails migrations?

• Should I flatten Rails migrations?

---

P.S.: I found it useful to stick with the old migration numbering scheme, where the migrations do not use timestamps - for me this works better (is easier to see in which order they are).

e.g. in your config/application.rb file:

config.active_record.timestamped_migrations = false

Keeping track of completed migrations in rails when using config.active_record.schema_format = :sql

I tracked down the problem...

Rails ActiveRecord does append INSERT statements for each up migration at the end of the structure.sql file.

The problem wound up being a problem in the activerecord-postgis-adapter gem which overrides the db:structure:dump rake task and does not append the said INSERT statement. I submitted a pull request to fix the problem.

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

Loading the DB dumb, and running all the migrations

I would first load the db dump, as it also contains all you data and the current schema structure.

running rake db:migrate will only run the new migration

This depends. If your db dump has a schema_migrations table, that lists all the previously applied migrations, it will not apply the migrations. Otherwise, it will try to and fail.

You basically need these steps:

1. Import your dump
2. Create a Rails schema (rake db:schema:dump)
3. If you have newer migrations, run them

---

Related Topics