Вопрос

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

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

Я думаю про себя: ты не шучу, Рейк...ты создал это!Я запустил трассировку на rake, и кажется, что rake думает, что это первый раз, когда он запускается.Однако, проанализировав мою таблицу «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.

Нет правильного решения

Другие советы

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

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

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

Если да, то какой адаптер базы данных ActiveRecord вы используете?(Какой у вас файл data.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 и версией для разработчиков.Есть ли запись в обеих таблицах (должен быть только один столбец, «версия», верно) или есть одна запись в базе данных разработки и ноль записей в рабочей среде?Если в производственной таблице нулевые записи, то сделайте следующее:

    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 задача только для первого создания, дополнительные изменения должны быть перенесены.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top