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

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

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

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

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

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

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

rake db:migrate RAILS_ENV=production

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

RAILS_ENV=production rake db:migrate

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

Что касается вашего обновления:

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

   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 в своей производственной среде, выполнить либо «требование», либо «загрузку» (я никогда не могу вспомнить, что именно или если это имеет значение) файла миграции, который вы хотите загрузить, а затем вызвать MyMigrationClass.up . После этого вам нужно будет вручную установить номер версии в таблице schema_migrations, так как у вас все еще будет проблема в будущем, но в качестве быстрого исправления это сработает.

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

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

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

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

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

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

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

rake db:migrate RAILS_ENV=production

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