миграция рельсов, очевидно, вызывает бесконечное разветвление - PullRequest
0 голосов
/ 26 февраля 2019

Сегодня я столкнулся с проблемой, что до сих пор мне не удалось отследить удачу.Я создал новый файл миграции (через 'rails g migrate ...').После создания файла, когда я запускаю rails db: migrate или rails db: migrate: status, в результате получается, что rails начинает бесконечно запускаться, то есть разветвляется.Если я удаляю новый файл миграции, этого больше не происходит - например, rails db: migrate: status приводит к отображению и завершению отчета о состоянии.Чтобы убедиться, что rails разветвлялся, когда я запустил миграцию, я запустил в отдельном терминале:

while :; do date;echo ....................;pgrep -laf ruby; sleep 1; done

После запуска rails db: migrate из приведенной выше команды появляется следующий шаблон:

Tue Feb 26 09:59:59 CST 2019
....................
23799 /home/jtc/.rvm/rubies/ruby-2.3.0/bin/ruby bin/rails db:migrate:status
Tue Feb 26 10:00:02 CST 2019
....................
23799 /home/jtc/.rvm/rubies/ruby-2.3.0/bin/ruby bin/rails db:migrate:status
23819 ruby bin/rails db:test:prepare
23837 /usr/bin/ruby-mri /home3/development/jtc/projects/s-todo/src/main/initial-
processing.rb
Tue Feb 26 10:00:03 CST 2019
....................
23799 /home/jtc/.rvm/rubies/ruby-2.3.0/bin/ruby bin/rails db:migrate:status
23819 ruby bin/rails db:test:prepare
Tue Feb 26 10:00:04 CST 2019
....................
23799 /home/jtc/.rvm/rubies/ruby-2.3.0/bin/ruby bin/rails db:migrate:status
23819 ruby bin/rails db:test:prepare
23875 ruby bin/rails db:test:prepare
Tue Feb 26 10:00:06 CST 2019
....................
23799 /home/jtc/.rvm/rubies/ruby-2.3.0/bin/ruby bin/rails db:migrate:status
23819 ruby bin/rails db:test:prepare
23875 ruby bin/rails db:test:prepare
23886 ruby bin/rails db:test:prepare

Как видите, команда, которая разветвляется, это 'ruby ... db: test: prepare'.Еще пара деталей:

Другие rails (не задачи db :) (все, что я пробовал до сих пор) производят то же самое поведение - т.е. разветвляются, когда новый файл миграции находится на месте, и работают нормально, когда онне там.Когда я запускаю сервер rails, эта проблема не возникает.Я считаю, что это происходит только при выполнении задач rails / rake.Кроме того, я подозревал, что причиной этого могут быть изменения, которые я внес в config / application.rb.Но после того, как я попробовал пару более старых версий этого файла (даты, когда миграции не были разветвлены) и столкнулся с той же проблемой, я пришел к выводу, что это, вероятно, не является фактором.Наконец, я также заметил, что задачи rails в последнее время выполняются с тестовой средой - то есть, в конце выполнения (без нового файла миграции) я вижу это:

Progress: |====================================================================|
Run options: --seed 37369

# Running:

Finished in 0.00505s
0 tests, 0 assertions, 0 failures, 0 errors, 0 skips

Finished in 0.004874s, 0.0000 runs/s, 0.0000 assertions/s.
0 runs, 0 assertions, 0 failures, 0 errors, 0 skips

Я сильно подозреваючто две проблемы связаны.Я начал изучать, что я изменил со времени последней успешной миграции (13 февраля), но пока не нашел подозреваемых.

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

Ответы [ 2 ]

0 голосов
/ 01 марта 2019

ОК, я нашел причину проблемы.Я думал, что отвечу на свой вопрос здесь, если это поможет другим с подобной проблемой.Я обнаружил, что когда вы запускаете задачу rails, все ваши задачи загружаются (я полагаю, все файлы * .rake в lib / tasks /).Я решил спрятать свои файлы * .rake (в каталоге chmod 000) и восстановить их по 1 или 2 за раз, чтобы выяснить, не является ли один из них причиной проблемы;и, сделав это, я нашел виновника - грабли, которая повторно использовала часть моего тестового кода для создания некоторых экземпляров модели и вставки соответствующих записей в базу данных, чтобы протестировать / отладить (то, что я называю) службу, которую яработал над.Очевидно, именно поэтому тестовый фреймворк запускался, несмотря на то, что проблема обнаружилась в режиме разработки - поскольку все файлы rake загружены, этот тестовый код также был загружен ... А поскольку при загрузке ruby ​​код подразумевает выполнение некоторого кодазагружаемый тестовый код должен был вызвать настройку тестовой среды - и, кроме того, некоторая циклическая зависимость должна быть вызвана выполнением этого «заимствованного» тестового кода, что приводит к некой бесконечной рекурсии и разветвлению.(Я не исследовал точную причину этого, так как это может занять некоторое время, и его остановка заключается в простом закомментировании кода-нарушителя или удалении файла rake. В итоге я окружил код-нарушитель защитным ключом - т.е. «if ENV»['ODD_ENV_VAR'] затем ... конец ", так что я все еще могу использовать его, когда мне это нужно.)

Так что для тех, кто видит те же симптомы - бесконечное разветвление и / или тестовая среда, в которой выполняетсяРежим разработки (или, возможно, схожие странные проблемы), который возникает только при выполнении задач rails / rake, я бы сказал, что файлы rake должны быть первыми, на которые стоит обратить внимание, даже перед использованием git checkout ..., чтобы выяснить это.когда проблема была введена.

0 голосов
/ 27 февраля 2019

Я предполагаю, что вы не сделали что-то разумное, например, использовали git или что-то для отслеживания версий (если так, просто откатите все).

На всякий случай я бы остановился (или kill при необходимости) любой spring, который работает.

В случае устранения этой проблемы я бы порекомендовал создать новое приложение, скопировать ваши миграции и запустить их в новом приложении, чтобы убедиться, что это не ваши миграции.Затем просто скопируйте ваш app и другие изменения.Затем установите и используйте git или что-то в этом роде, чтобы такие проблемы решались в будущем:)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...