Каков наилучший способ разрешить несанкционированные миграции Rails?

Я, наконец, сделал это с помощью scalaj-http вместо Dispatch. Вызов синхронный, но это соответствует моему варианту использования.

Я думаю, что Spark Job никогда не заканчивает использование Dispatch, потому что соединение Http не было закрыто должным образом.

С наилучшими пожеланиями

29
задан Adrian 22 April 2013 в 19:40
поделиться

6 ответов

Я решил проблему следующим образом:

(1) Перейдите к веткам, в которых есть файлы миграции, и откатите их назад. Это не тривиально, когда у вас много ветвей, которые приведут к множеству конфликтов, если вы попытаетесь объединить их. Поэтому я использую эти команды, чтобы узнать, к каким ветвям принадлежит каждая сиротская миграция.

Итак, мне нужно найти коммит последнего изменения миграции.

git log --all --reverse --stat | grep <LASTEST_ORPHAN_MIGRATION_ID> -C 10

Я беру хеш коммита и определяю, к какой ветви он принадлежит, например:

git branch --contains <COMMIT_HASH>

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

(2) Запустите миграцию: извлеките ветку, над которой вы, наконец, хотите поработать, и запустите миграции, и вы должны быть в порядке.

Устранение неполадок

Я также работал в некоторых случаях, когда осиротевшие миграции были на удаленных ветвях.

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

Другой альтернативой является прямое удаление отсутствующих файлов из базы данных:

delete from schema_migrations where version='<MIGRATION_ID>';
50
ответ дан Adrian 22 April 2013 в 19:40
поделиться

Миграции хранятся в вашей базе данных. Если вы хотите удалить оставленные миграции, удалите их из базы данных.

Пример для Postgres:

  1. Open psql:

    psql
    
  2. Подключитесь к своей базе данных:

    \c your_database
    
  3. Если вам интересно, отобразите schema_migrations:

    SELECT * FROM schema_migrations;
    
  4. Если вам интересно, проверьте, есть ли оставленные миграции:

    SELECT version FROM schema_migrations WHERE version IN 
    ('20130320144219', '20130320161939', '20130320184628', '20130403190042',
     '20130403195300', '20130403214000', '20130410194222');
    
  5. Удалить их:

    DELETE FROM schema_migrations WHERE version IN (<version list as above>);
    

Теперь, если вы запустите bundle exec rake db:migrate:status, вы увидите, что осиротевшие миграции были успешно удалены.

27
ответ дан medik 22 April 2013 в 19:40
поделиться

Редактировать: Как сказано в комментариях, следующее УБРОСИТ ВАШУ БАЗУ ДАННЫХ

Более простой подход, который сработал для меня (обратите внимание, что эта команда удалит базу данных и все ваши данные будут потеряны):

rake db:migrate:reset

.., а затем:

rake db:migrate:status

Сирота (и) должны исчезнуть.

17
ответ дан Joe Van Dyk 22 April 2013 в 19:40
поделиться

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

git checkout <commit hash> <file_name>

(Благодаря этот ответ )

В качестве альтернативы, вы можете извлечь из конкретная ветка HEAD:

git checkout <branch name> -- <file_name>

Согласно этому сообщению в блоге

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

0
ответ дан Community 22 April 2013 в 19:40
поделиться

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

0
ответ дан Whit Kemmey 22 April 2013 в 19:40
поделиться

Если файлы миграции действительно отсутствуют (например, запустили миграцию, забыли откатить миграцию, затем удалили файл миграции перед фиксацией), я смог воспроизвести отсутствующую миграцию следующим образом:

  1. go вернуться в историю git, чтобы получить копию файла schema.rb и сохранить его вне git repo (git log; git checkout xxxxxx; cp schema.rb ~/schema_old.rb, git checkout master).
  2. запустить diff для двух файлов и скопировать команды миграции в файл миграции, соответствующий отсутствующий идентификатор миграции (diff schema.rb ~/schema_old.rb > migration_file.rb; vi migration_file.rb)
  3. Проверьте статус миграции и откат (rake db:migrate:status; rake db:rollback; rake db:migrate:status;)
0
ответ дан Taylored Web Sites 22 April 2013 в 19:40
поделиться
Другие вопросы по тегам:

Похожие вопросы: