Как пропустить миграцию рельсов после создания базы данных из дампа

Если вы восстанавливаете базу данных из дампа, таблица schema_migrations должна восстанавливаться вместе с остальными таблицами.

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

Идеальным решением было бы восстановить резервную копию, в которой правильно указаны все таблицы, включая schema_migrations.

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

С точки зрения того, что делать сейчас, идеальное решение, вероятно, состоит в том, чтобы сделать резервную копию только этой одной таблицы (schema_migrations) из вашей базы данных и импортировать эти данные в базу данных, которую вы пытаетесь загрузить сейчас. Тогда ваши миграции больше не должны быть ожидающими.

Делать это с помощью простого дампа таблицы и сценария загрузки должно быть хорошо. Простой графический интерфейс postgres PgAdmin ( http://www.pgadmin.org/ ) также может предоставить некоторые базовые инструменты для создания дампа и загрузки одной таблицы.

Кевин прав. Однако ему не хватает критической точки.

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

Однако ваш код на тридцать миграций опережает моментальный снимок вашей базы данных, представленный резервной копией.

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

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

Не переживайте и обновитесь завтра, когда в резервной копии будут ваши изменения.

Вы также можете вручную добавить временные метки отсутствующих миграций в таблицу БД, например:

INSERT INTO "public"."schema_migrations"("version") VALUES ('20201212012345')

Это должно иметь тот же эффект, что и временное закомментирование инструкций «создать» в файлах миграции. Если вы запускаете миграцию как часть процесса развертывания из git, комментирование будет означать, что вам нужно отправить эти изменения в git.

Если вы просто работаете над созданием/разработкой среды, непосредственное исправление базы данных может быть лучше, чем внесение этих изменений, что может сбить с толку других развертываний или разработчиков.