How to skip rail migration after creating a database from a dump

Question

I restored my database from the last dump and tried to run rake tests. Unfortunately, 30 migrations were delayed. My first idea was to comment on each of the 30 migration codes and run "rake db: migrate", but there should be a simpler solution. I am using Rails 2.3.14 and Postgresql 9.1.3.

Answer 1

If you are restoring a database from a dump, the schema_migrations table should be restored along with the rest of the tables.

This seems to indicate that your schema_migrations table cannot be copied, which will lead to the problem that you have now.

An ideal solution would be to restore a backup in which all tables should be correct - including schema_migrations .

Even if you decide to find a way around this in the short run, in the long run the right solution is to modify your backup scripts to get all the tables you need, including schema_migrations .

In terms of what to do now, the ideal solution is probaby to backup only one table ( schema_migrations ) from your database and import this data into the database that you are currently loading. Then your migrations will no longer be expected.

Doing this with a simple dump of the table and loading the script should be fine. Simple postgres gui PgAdmin ( http://www.pgadmin.org/ ) can also provide some basic reset tools, and then load a single table.

Answer 2

Kevin is right. However, he lacks a critical point.

When restoring from a backup, the schema_migrations table is restored, which keeps track of which migrations to perform. If these thirty migrations were run in the database that you restored, they will not work.

However, your code is thirty jumps in front of a snapshot of your backup database.

This can happen to me if I turn around and then take a backup right away. Although the migrations were done in production, I get a backup until working hours before my deployment. I usually like to wait a day and get a backup the next day.

Or, don't worry about it. Your backup is located before these thirty migrations, but then they were applied, so the migrations made your scheme match the version of your code. This is a good thing.

Do not sweat and update again tomorrow when the backup has your changes.