Подтвердить что ты не робот

Перенос маркеров Rails

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

Я переместил один набор дублированных 9 из каталогов рельсов на производственном сервере, но теперь, когда я хочу 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, чтобы забыть все выдающиеся миграции, эффективно отмечая все выдающиеся миграции как выполненные?

4b9b3361

Ответ 1

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

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

Ответ 2

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

  • Перейдите в конфликтный файл миграции.

  • Удалите содержимое и сохраните его.

  • Выполнить rake db:migrate

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

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

Ответ 3

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