Модели ActiveRecord теряют свои методы find_by_ *

У нас есть относительно стандартный проект Ruby on Rails, в котором довольно много фоновых заданий, выполняемых под Resque (с Redis в качестве бэкэнда).

Проблема в том, что очень редко - возможно, раз в месяц, а может, и реже - мы внезапно увидим поток исключений из Resque. Исключения следующие:

undefined method `find_by_id` for User():Class
undefined method `find_by_name` for CustomerAccount():Class
undefined method `find_by_id` for Job():Class

Кажется, что внезапно все модели ActiveRecord :: Base теряют свои find_by_* методы для всего потока. Перезапуск рабочего решает проблему.

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

Этот проект работает под управлением Ruby 2.1.1p76, Rails 3.2.17, Resque 1.25.1.


ruby ruby-on-rails activerecord resque
person Elliot Nelson    schedule 31.10.2014    source источник
comment
Я знаю, что эти средства поиска устарели в Rails 4.0, и есть гем, который их возвращает (github.com/rails / activerecord-deprecated_finders), но похоже, что вы ничего подобного не используете ...   -  person D-side    schedule 31.10.2014
comment
Можете ли вы заменить эти методы на where(...).first? Они все равно уйдут, так что вам рано или поздно придется их заменить. Вы также можете пропатчить find_by(x) (как where(x).first) в ActiveRecord и использовать его вместо этого, find_by входит в состав Rails4, поэтому ваш код будет совместим с будущим, вам просто нужно не забыть убить свой обезьяний патч при обновлении.   -  person mu is too short    schedule 31.10.2014
comment
@ Боковые рельсы D 4.0 не обесценились find_by_xxx. См. здесь. Они обесценили многие из динамических поисковых систем, но их нет в списке. Хотя, похоже, это заблуждение, распространившееся на многих разработчиков.   -  person engineersmnky    schedule 31.10.2014
comment
@engineersmnky Понятно. Тем не менее, это Rails 3. Так что мой первый комментарий в целом бесполезен. Однако это может помешать некоторым людям блуждать в этом направлении.   -  person D-side    schedule 31.10.2014
comment
find_by_* методы реализованы через _2 _ / _ 3_. respond_to? проверяет, существует ли столбец с определенным именем. Я предполагаю, что если ваше соединение с базой данных в какой-то момент по какой-то причине не удается, вы начинаете получать эти ошибки, поскольку набор столбцов, известный вашему приложению, пуст. Можете ли вы проверить свои журналы на наличие следов сбойных / закрытых соединений в воркерах?   -  person moonfly    schedule 04.11.2014
comment
возможный дубликат эквивалента find_all_by_id в рельсах 4   -  person Brad Werth    schedule 07.08.2015
comment
@moonfly Оказывается, проблема действительно в разрыве соединения с базой данных; зная первопричину, было легко добавить проверки и переподключиться. Если вы хотите превратить свой комментарий в ответ, я с радостью присуждаю какой-то древний и долгожданный ответ.   -  person Elliot Nelson    schedule 31.08.2018

Ответы (1)


arrow_upward
1
arrow_downward

Замыкание цикла по этому древнему вопросу: оказалось, что проблема была в комментарии moonfly, и у длительно работающих воркеров разорванное соединение с базой данных привело бы к этому (несколько странному) сообщению об ошибке.

Зная основную причину, мы смогли добавить периодическое обновление соединения (чтобы попытаться сохранить соединение, когда рабочий слишком долго бездействовал), а также добавить механизм обнаружения, когда db conn было < / em> сбросил и переподключить. Итак, большое спасибо @moonfly, если вы хотите превратить свой комментарий в ответ, я счастлив наградить вас кредитом на ответ с большой задержкой.

person Elliot Nelson    schedule 31.08.2018