2009-12-27 2 views
2

В какой-то момент в развитии моих рельсов я начал делать изменения в базе данных (например, удалять или изменять столбцы/таблицы) без использования переходов рельсов. Так что теперь я получаю ошибки, когда пытаюсь развернуть приложение rails с нуля.Мои миграции рельсов не запускаются, и я не могу развернуть приложение rails. Как мне начать?

[email protected] ~/tmp/rbjacolyte $ rake db:migrate 
(in /home/blaine/tmp/rbjacolyte) 
== AddHashToTrack: migrating ================================================= 
-- add_column(:tracks, :hash, :string) 
rake aborted! 
An error has occurred, all later migrations canceled: 

Mysql::Error: Table 'jacolyte_dev_tmp.tracks' doesn't exist: ALTER TABLE `tracks` ADD `hash` varchar(255) 

(See full trace by running task with --trace) 

Как синхронизировать среду разработки и разработки с миграциями после того, как я удалил ее с помощью необработанного SQL? Я хочу развернуть приложение rails без ошибок базы данных, и я не хочу начинать с нуля.


Данные в производственных и производственных средах совпадают, но миграции терпят неудачу. Я хочу, чтобы «начать с нуля».

Могу ли я просто удалить все миграции, которые у меня есть, а затем только начать использовать миграции?

ответ

1

Путь быстрого доступа: вручную добавьте запись в schema_migrations для отметки времени, которая представляет базовую линию. После этого вы можете добавить миграции и до тех пор, пока они не сделают каких-либо плохих предположений о схеме db, они должны иметь возможность работать нормально. Вы не сможете перейти назад, но это не проблема.

Большая проблема заключается в том, что вы не сможете сделать БД с нуля, что становится больно более длительным сроком.

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

Пока ваш прямой SQL содержится в миграции Rails, нет проблем с его использованием. Просто убедитесь, что вы применяете методы #up и #down, и вы должны быть хорошими. Фактически мы использовали для использования SQL-кода как лучший метод, чтобы избежать проблем, когда модели впоследствии меняются. Что-то вроде

Foo.create(:name => 'bar') 

кажется безобидным, пока модель пользователя не изменяется, чтобы иметь

validates_presence_of :baz 

В этот момент новая миграция будет работать с существующей базой данных, но что ранее миграции, который создал таблицу и добавил фиктивная запись завершится неудачно, поскольку пользователь завершит проверку. Только с использованием

execute("insert into foos (name) values ('bar')") 

будет работать нормально, если последующие миграции должным образом заполняют новые столбцы, которые они добавляют.

0

Если существующие производственные данные совместимы со схемой базы данных разработки, то я бы:

  1. дампа производственных данных в файл с помощью программы, таких как mysqldump
  2. отброшенных производственной базы данных
  3. Восстановить производственную базу данных
  4. Запустить миграцию с производственной базой данных, указав VERSION = 0
  5. Импортировать производственные данные из файла созданный на шаге 1

Если схемы несовместимы, вы можете следить за этим процессом, но вам нужно будет отредактировать SQL в файле, созданном на первом этапе, чтобы учитывать различия схем ,

+0

Данные как в производстве, так и в разработке совместимы друг с другом. Еще одна проблема: миграции не будут выполняться ни по производству, ни по разработке, потому что я сделал много изменений с использованием необработанного SQL или Sequel ORM. –

+0

Мне просто нужен способ «начать с нуля», так сказать. Миграции не синхронизированы с базой данных. Например, миграции выполняются, но сбой, потому что я удалю базу данных с необработанным SQL, а не с миграцией ... поэтому миграции будут думать, что они все еще существуют, и попытаться удалить их, но сбой. –

+0

Если вы укажете VERSION = 0 при запуске миграции, она будет запускать их с самого начала. –

1

Возможно, вы могли бы просто избавиться от всех текущих миграций и использовать rake db:schema:dump для создания нового файла schema.rb и вручную отредактировать свою производственную базу данных, чтобы отразить изменения, которые вы сделали до сих пор?

0

Мне нравится предложение Veeti с модификацией: rake db: schema: dump, а затем переместите этот файл на вашу машину разработки. Сгладьте миграцию Rails до сих пор (см. this SO thread on that), избавитесь от большинства ваших миграций и переработайте свои миграции для работы, учитывая вашу новую схему.

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

 Смежные вопросы

  • Нет связанных вопросов^_^