Выявление ошибок с помощью Ruby Twitter gem, методы кеширования с использованием delayed_job: Что я делаю не так?

Во-первых, какова точная ошибка, которую вы получаете, и что вы хотите, чтобы произошло ее появление?

Редактировать:

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

def self.cache_retweets_for_all_auths
  @authentications = Authentication.find_all_by_provider("twitter")

  @authentications.each do |authentication|
    being
      authentication.user.twitter.retweeted_to_me(include_entities: true, count: 200).each do |tweet|
        # Actually build the cache - this is good - removing to keep this short
      end
     rescue => e
       #Either create an object where the error is log, or output it to what ever log you wish.
     end
  end
end

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

Далее, когда вам следует использовать what.

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

Другими словами

Планировщик будет в порядке, если время между обновлениями X меньше, чем время, необходимое для выполнения обновления, время Y.

Если X ‹Y, тогда вы можете захотеть посмотреть на вызов логики из контроллера при доступе к каждой отдельной записи, вместо того, чтобы пытаться сделать их все сразу. Идея в том, что вы обновляете его только по прошествии определенного времени. Вы можете сохранить последнее обновление либо в самой модели в поле типа twitter_udpate_time, либо в экземпляре redis или memecache с ключом unquie для пользователя / auth.

Но если отдельное обновление по-прежнему слишком велико, тогда вам следует выполнить описанное выше, но вместо того, чтобы выполнять фактическое обновление, вызовите отложенное задание.

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

Возможные модные штаны

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

Рядом с ником придирчивый.

http://api.rubyonrails.org/classes/ActiveRecord/Batches.html

Вы должны использовать

@authentications.find_each do |authentication|

вместо того

@authentications.each do |authentication|

find_each извлекает только 1000 записей за раз, поэтому, если вы получите много аутентификаций, вы не получите сумасшедшее количество записей в памяти.