interrogation avec delayed_job

Commençons avec l'API. J'aimerais avoir quelque chose comme ce qui suit.

@available.working? # => true or false, so we know it's running
@available.finished? # => true or false, so we know it's finished (already ran)

Maintenant, nous allons écrire le travail.

class AwesomeJob < Struct.new(:options)

  def perform
    do_something_with(options[:var])
  end

end

So far So good. Nous avons un emploi. Maintenant, nous allons écrire une logique qui place en file d'attente il. Depuis Disponible est le modèle de la responsable de ce travail, nous allons l'enseigner comment démarrer ce travail.

class Available < ActiveRecord::Base

  def start_working!
    Delayed::Job.enqueue(AwesomeJob.new(options))
  end

  def working?
    # not sure what to put here yet
  end

  def finished?
    # not sure what to put here yet
  end

end

Alors, comment savons-nous si le travail est travail ou pas? Il y a un peu de moyens, mais dans les rails, il se sent juste raison, quand mon modèle crée quelque chose, il est généralement associé avec quelque chose. Comment pouvons-nous associer? L'utilisation d'identifiants dans la base de données. Nous allons ajouter un job_id sur les modèles Disponibles.

Pendant que nous y sommes, comment savons-nous que le travail n'est pas de travail parce que c'est déjà fini, ou parce qu'il n'a pas commencé encore? Une façon est de vérifier pour ce que le travail fait. Si il a créé un fichier, vérifier si le fichier existe. Si elle calculée une valeur, vérifier que le résultat est écrit. Certains emplois ne sont pas faciles à vérifier si, puisqu'il peut ne pas être clair vérifiables résultat de leur travail. Dans de tels cas, vous pouvez utiliser un drapeau ou un timestamp dans votre modèle. En supposant que c'est notre cas, nous allons ajouter un job_finished_at horodatage de distinguer un pas encore couru travail à partir d'un déjà fini un.

class AddJobIdToAvailable < ActiveRecord::Migration
  def self.up
    add_column :available, :job_id, :integer
    add_column :available, :job_finished_at, :datetime
  end

  def self.down
    remove_column :available, :job_id
    remove_column :available, :job_finished_at
  end
end

Bien. Alors maintenant, nous allons réellement associer Available avec son travail, dès que nous mettre en file d'attente le travail, par la modification de la start_working! méthode.

def start_working!
  job = Delayed::Job.enqueue(AwesomeJob.new(options))
  update_attribute(:job_id, job.id)
end

Grande. À ce point, j'aurais pu écrire belongs_to :job, mais nous n'avons pas vraiment besoin de ça.

Alors maintenant, nous savons comment écrire le working? méthode, si facile.

def working?
  job_id.present?
end

Mais comment marquer le travail terminé? Personne ne connait un travail a fini de mieux que le travail lui-même. Donc, nous allons passer available_id dans le travail (comme l'une des options) et de l'utiliser dans le travail. Pour cela nous avons besoin de modifier la start_working! méthode pour transmettre l'id.

def start_working!
  job = Delayed::Job.enqueue(AwesomeJob.new(options.merge(:available_id => id))
  update_attribute(:job_id, job.id)
end

Et il convient d'ajouter la logique dans le travail de mise à jour de notre job_finished_at horodatage quand c'est fait.

class AwesomeJob < Struct.new(:options)

  def perform
    available = Available.find(options[:available_id])
    do_something_with(options[:var])

    # Depending on whether you consider an error'ed job to be finished
    # you may want to put this under an ensure. This way the job
    # will be deemed finished even if it error'ed out.
    available.update_attribute(:job_finished_at, Time.current)
  end

end

Avec ce code à la place, nous savons comment écrire notre finished? méthode.

def finished?
  job_finished_at.present?
end

Et nous y sommes. Maintenant, nous pouvons simplement sondage contre @available.working? et @available.finished? Aussi, vous bénéficiez de la commodité de le savoir exact travail a été créé pour votre Disponible en vérifiant @available.job_id. Vous pouvez facilement le transformer en véritable association en disant belongs_to :job.

Je pense que le meilleur moyen serait d'utiliser les callbacks disponibles dans la delayed_job.
Ce sont:
:le succès, l' :erreur et :after.
ainsi, vous pouvez mettre un peu de code dans votre modèle avec le après:

class ToBeDelayed
  def perform
    # do something
  end

  def after(job)
    # do something
  end
end

Parce que si vous insistez de l'aide de l'obj.retardée.méthode, alors vous aurez à monkey patch Différés::PerformableMethod et ajouter le after méthode là.
À mon humble avis c'est beaucoup mieux que l'interrogation de la valeur qui pourrait être encore backend spécifique (ActiveRecord vs Mongoid, par exemple).

Je proposerais que s'il est important d'obtenir notification que le travail est terminé, puis d'écrire un personnalisé objet de la tâche et de la file d'attente que plutôt que de compter sur le travail par défaut qui obtient en file d'attente lorsque vous appelez Available.delay.dosomething. Créer un objet, quelque chose comme:

class DoSomethingAvailableJob

  attr_accessor options

  def initialize(options = {})
    @options = options
  end

  def perform
    Available.dosomething(@options)
    # Do some sort of notification here
    # ...
  end
end

et mettre en file d'attente avec:

Delayed::Job.enqueue DoSomethingAvailableJob.new(:var => 1234)