A
A
Akhmad Zakhratulaev2016-11-06 12:48:15
Ruby on Rails
Akhmad Zakhratulaev, 2016-11-06 12:48:15

Lost migrations, how best to fix the server and deploy the project on a working computer?

The production server itself is working, the deployment occurs through capistrano, when errors with migrations came out, we had to add and remove migrations directly on the server (which were lost due to incorrect use of the VCS (git)) and it is not possible to track what and where is lost.
There was an idea to rewrite all the migrations, delete the old ones, run the new ones (so that the schema file is up-to-date and you can run the project for developers on other computers) and use the dump of the working database with data (on the production server).
I rewrote the migrations, rolled it up, changed the database, added a version from the schema in the dump of the old database to the schema_migrations table. Doesn't start says:
ActiveRecord::PendingMigrationError
Migrations are pending. To resolve this issue, run: bin/rake db:migrate RAILS_ENV=development An
error occurs when running the command because the tables already exist.
ruby 2.2.0
rails 4.2.0
mysql2 0.3.18
Bundler version 1.13.6
rake >= 10.0.0
Actually, the question is how can I make friends with the old database with the application (on working computers and is it worth editing migrations on the server). In the future, it turns out that you still need to put things in order inside the database, for this I thought inside mysql (on the production server) manually delete unused tables and indexes, add missing indexes (in new migrations, unused tables are not described, but non-existent indexes are described). Of course, I understand that most likely I made a lot of mistakes, but in the future I will try to maintain the database properly, thanks for your attention.

Answer the question

In order to leave comments, you need to log in

1 answer(s)
@
@mgyk, 2016-11-08
@asker13

Raise better from the schema (schema.rb) and store it in git. It is necessary that there are only those migrations that are relevant for production +/- a few if you need to do a rollback. You do not need to keep the entire history of migrations from the beginning of the project. That is, you can dump the schema in production and pull it into git. This will be your exact reference.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question