Почему rake выдает ошибку миграции Rails?

Question

У меня есть две машины ... машина для разработки и машина для производства. Когда я впервые перенес свое приложение rails на рабочий сервер, у меня не было проблем. Я просто импортировал schema.rb, запустив rake db: schema: load RAILS_ENV = production. Все было хорошо.

Итак, затем на своей машине для разработки я сделал еще несколько изменений и еще одну миграцию, а затем скопировал новое приложение на рабочую машину. Затем я попытался обновить базу данных, запустив rake db: migrate RAILS_ENV = production. Я получаю следующую ошибку: «В базе данных уже есть объект с именем schema_migrations.»

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

Я также пытался явно указать номер версии, но это тоже не работает.

Есть идеи о том, как обновить мой рабочий сервер?

Обновление:

Позвольте мне начать с того, что я не могу просто «отбросить» базу данных. Это рабочий сервер, на котором уже находится более 100 тысяч записей. Что произойдет, если подобная проблема возникнет в будущем? Я должен просто отбрасывать таблицу каждый раз, когда возникает проблема с базой данных? На этот раз это может сработать, но не похоже на практическое долгосрочное решение каждой проблемы с базой данных. Я сомневаюсь, что проблема, с которой я столкнулся сейчас, уникальна для меня.

1. Звучит так, будто таблица 'schema_info' и таблица 'schema_migrations' совпадают. В моей настройке у меня есть только «schema_migrations». Как указывалось ранее, разница между таблицей schema_migrations на рабочем сервере и компьютере разработчика составляет всего одну запись. То есть запись, содержащая номер версии изменения, которое я хочу перенести.

2. Из книги, которую я прочитал, «Просто Rails 2», говорится, что при первом переходе на рабочий сервер вместо запуска rake db: migrate нужно просто запустить rake: db: schema: load.

3. Если это имеет значение, я использую Rails версии 2.1.

Answer 1

В зависимости от системы, используемой в производстве, я видел случаи, когда нижеприведенное работает , а не :

rake db:migrate RAILS_ENV=production

Но где этот работает:

RAILS_ENV=production rake db:migrate

Причудливый, я знаю, но стоит попробовать, чтобы увидеть, если это что-то меняет.

Answer 2

Если вы получаете «В базе данных уже есть объект с именем« schema_migrations ».» сообщение об ошибке, то я подозреваю, что вы используете MS SQLServer в качестве базы данных? (Это выглядит как сообщение об ошибке MS SQL Server)

Если да, то какой адаптер базы данных ActiveRecord вы используете? (Что такое файл database.yml, какие гемы вы установили для доступа к базе данных MS SQL Server?)

В настоящее время кажется, что Rails не находит таблицу schema_migrations в рабочей схеме и поэтому пытается ее создать, и это создание завершается неудачно с сообщением об ошибке базы данных. Вероятно, причина в верхнем / нижнем регистре символов в имени таблицы schema_migrations - насколько я понимаю, идентификаторы MS SQL Server чувствительны к регистру.

Answer 3

По поводу вашего обновления:

1. Я не понимаю, в чем разница между вашей производственной schema_migrations и версией dev. Есть ли запись в обеих таблицах (должен быть только 1 столбец, «версия», справа), или есть одна запись в базе данных dev и ноль записей в производстве? Если в рабочей таблице ноль записей, сделайте следующее:

   ActiveRecord::Base.connection.execute("INSERT schema_migrations (version) VALUES(#{my version number that production is supposedly on})")

2. В качестве альтернативы, вы можете попробовать полностью сбросить таблицу schema_migrations на производстве:

   ActiveRecord::Base.connection.execute("DROP TABLE schema_migrations")

   Затем снова запустите rake db:migrate RAILS_ENV=production. Это запустит миграцию, начиная с версии 1, хотя, вероятно, это не то, что вам нужно.

3. В качестве альтернативы, вы можете запустить сеанс IRB в своей производственной среде, выполнить команду «require» или «load» (я никогда не могу вспомнить, какой, или если это имеет значение) файла миграции, который вы хотите загрузить, а затем позвоните MyMigrationClass.up. После этого вам нужно будет вручную установить номер версии в таблице schema_migrations, поскольку у вас по-прежнему будет возникать проблема в будущем, но для быстрого взлома это будет работать.

Answer 4

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

Тем не менее ... вы говорите, что вы смотрели в таблицу "schema_migrations", и что есть разница в одной версии от dev до рабочей ... Я не слышал об этой таблице, хотя я несколько месяцев позади на моей версии рельсов. Возможно, вы можете попытаться создать таблицу «schema_info» в производственной среде с одним столбцом «version» и добавить строку с версией, в которой, по вашему мнению, находится ваша производственная среда.

Answer 5

Я знаю, что это сообщение было некоторое время назад, но я наткнулся на него, и на самом деле на него не было ответа. Как это происходит в Google, здесь идет.

Когда вы выполняли rake db: schema: dump (или когда это было сделано для вас сценариями сборки), оно поместит определение таблицы миграции в schema.rb. В конце сценария процесс попытается снова создать таблицу, однако она, очевидно, уже существует. Просто удалите таблицу миграции из schema.rb перед запуском rake: schema: load, и сообщения об ошибке не будет.

Вам потребуется установить номер версии в таблице миграции, чтобы впоследствии запустить миграцию. Поэтому важно знать, к какой версии относится ваш schema.rb, или удалить все старые миграции (они в безопасности в вашем SCM, верно?)

Answer 6

rake db: schema: load загрузит структуру базы данных из schema.rb. Этот файл является текущим представлением структуры базы данных. Он используется, когда у вас есть пустая схема (база данных), которая требует создания всех таблиц и индексов Это избавляет вас от необходимости выполнять все миграции. Если у вас есть существующая производственная база данных с данными, вы не хотите ее запускать. Как говорили другие, это было бы плохо!

Answer 7

schema_info из старой версии Rails. schema_migrations - новый ребенок в блоке. Вы должны быть в состоянии удалить таблицу schema_info, так как она больше не будет использоваться. Возможно, вы захотите найти любые проблемы, связанные с этим изменением имени.

Answer 8

rake db:migrate RAILS_ENV=production

Используйте задачу db:schema:load только для первого создания, необходимо перенести инкрементные изменения.

Answer 9

Я бы просто сбросил БД, добавил ее снова и запустил rake rb: migrate. Брэд прав, что когда вы запустили загрузку схемы, он не поместил никаких записей в таблицу schema_migrations.

Конечно, это сложнее, если есть данные, которые вы не можете потерять на рабочем сервере. Вы можете получить задачи резервного копирования rake (не уверены, является ли это частью ядра или нет), а затем запустить rake db: backup: write в вашей производственной базе данных, а затем, после того как вы получите последние обновления для рабочих сред, запустите rake db: резервное копирование: чтение

.