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

Question

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

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

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

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

Любые идеи о том, как я могу обновить свой производственный сервер?

Update:

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

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

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

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

Answer 2

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

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

Answer 3

rake db:migrate RAILS_ENV=production 

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

rake db:migrate RAILS_ENV=production 

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

RAILS_ENV=production rake db:migrate 

Необычных, я знаю, , но стоит попытаться понять, имеет ли это значение.

Answer 9

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

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

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