Маркировка Rails-миграций как перенесенных

Question

Я закончил с 9 дублированными миграциями. (Я думаю, что это потому, что я установил / обновил Gems и / или вытащил их миграции как на своих разработчиках, так и на производственных машинах, но на этом этапе я не совсем уверен.)

Я удалил один набор дубликатов 9 из каталогов rails на рабочем сервере, но теперь, когда я хочу db:migrate на производстве, чтобы запустить другую миграцию, я получаю:

$ bundle exec rake db:migrate RAILS_ENV=production
[DEPRECATION WARNING] Nested I18n namespace lookup under "activerecord.attributes.checkout" is no longer supported
==  CreatePages: migrating ====================================================
-- create_table(:pages)
rake aborted!
An error has occurred, all later migrations canceled:

Mysql2::Error: Table 'pages' already exists: CREATE TABLE `pages` (`id` int(11) DEFAULT NULL auto_increment PRIMARY KEY, `title` varchar(255), `body` text, `slug` varchar(255), `created_at` datetime, `updated_at` datetime) ENGINE=InnoDB

Это связано с тем, что миграции фактически уже выполнены.

Я бы предпочел не делать db:migrate:down и db:migrate:up для каждого - я думаю, это будет означать, что данные в производственной базе данных будут потеряны. (В этом случае пара статических страниц в Spree.)

Есть ли способ, с помощью которого я могу сказать этой установке Rails забыть обо всех незавершенных миграциях, эффективно пометив все незавершенные миграции как выполненные?

Answer 1

Я решил это так:

1. Перейти к конфликтующему файлу миграции.

2. Сотрите содержимое и сохраните его.

3. Пробег rake db:migrate

4. Ctrl + Z файл до предыдущего состояния.

Это был особый случай, потому что я скопировал БД из другого приложения, у меня были конфликтующие миграции и прочее.

Answer 2

Вы можете добавить метки времени миграций в таблицу schema_migrations.Однако почему эта таблица отсутствует в базе данных или пропускает строки, в которых она нуждается?

Вероятно, это тот случай, когда эта конкретная миграция прошла половину пути и не удалась, таким образом, когда вы пытаетесь запустить ее сновапервая часть миграции не будет работать, как это было сделано ранее.Это ограничение MySQL, так как он не может откатить изменения миграции, которые не проходят часть пути.Postgres, с другой стороны, может откатить структурные изменения в базе данных, избегая этой проблемы.

Answer 3

По умолчанию rake db:migrate запускает все ожидающие миграции. Итак, чтобы сделать ваши миграции правильными ... ради ... закомментируйте эти миграции и затем верните их в нормальное состояние. Это гарантирует, что вы будете в порядке в будущих миграциях.