Я, наконец, сделал это с помощью scalaj-http вместо Dispatch. Вызов синхронный, но это соответствует моему варианту использования.
Я думаю, что Spark Job никогда не заканчивает использование Dispatch, потому что соединение Http не было закрыто должным образом.
С наилучшими пожеланиями
Я решил проблему следующим образом:
(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>';
Миграции хранятся в вашей базе данных. Если вы хотите удалить оставленные миграции, удалите их из базы данных.
Пример для Postgres:
Open psql:
psql
Подключитесь к своей базе данных:
\c your_database
Если вам интересно, отобразите schema_migrations:
SELECT * FROM schema_migrations;
Если вам интересно, проверьте, есть ли оставленные миграции:
SELECT version FROM schema_migrations WHERE version IN
('20130320144219', '20130320161939', '20130320184628', '20130403190042',
'20130403195300', '20130403214000', '20130410194222');
Удалить их:
DELETE FROM schema_migrations WHERE version IN (<version list as above>);
Теперь, если вы запустите bundle exec rake db:migrate:status
, вы увидите, что осиротевшие миграции были успешно удалены.
Редактировать: Как сказано в комментариях, следующее УБРОСИТ ВАШУ БАЗУ ДАННЫХ
Более простой подход, который сработал для меня (обратите внимание, что эта команда удалит базу данных и все ваши данные будут потеряны):
rake db:migrate:reset
.., а затем:
rake db:migrate:status
Сирота (и) должны исчезнуть.
Предполагая, что вы используете Git, вам будет относительно просто захватить эти миграции и перенести их в вашу текущую ветку. Если у вас есть конкретный коммит, из которого вы хотите получить файл, вы можете использовать:
git checkout <commit hash> <file_name>
(Благодаря этот ответ )
В качестве альтернативы, вы можете извлечь из конкретная ветка HEAD:
git checkout <branch name> -- <file_name>
Согласно этому сообщению в блоге
Предполагая, что на самом деле это версии миграций, выполняемые в базе данных, вы должны хорошо бы откатиться.
Вы можете объединить две ветви обратно в мастер, чтобы у вас были доступны все миграции. Если вам действительно не нужны эти миграции, но вы хотите иметь возможность выполнить откат, вы можете отредактировать таблицу schema_migrations в вашей базе данных, чтобы удалить строки, соответствующие миграциям, для которых у вас нет файлов. Однако это вызовет проблемы, если вы затем переключитесь на другую ветку с другими миграциями.
Если файлы миграции действительно отсутствуют (например, запустили миграцию, забыли откатить миграцию, затем удалили файл миграции перед фиксацией), я смог воспроизвести отсутствующую миграцию следующим образом:
git log; git checkout xxxxxx; cp schema.rb ~/schema_old.rb, git checkout master)
. diff schema.rb ~/schema_old.rb > migration_file.rb; vi migration_file.rb
) rake db:migrate:status; rake db:rollback; rake db:migrate:status;
)