would it be possible to allow for unique delayed jobs?

[marbemac]

Similar to resque-loner? A use-case here is I put in a delayed job to send a notification email 30 minutes from now. If another notification is added before the 30 minutes I don't want to add another send email delayed job. When the job is run it aggregates all the new notifications and sends them in one email.

[bvandenbos]

I get this request (or very similar) every few months.

I am not fan of putting this functionality in resque-scheduler. It
should be easy enough for you to store the last time notifications ran
for a given user in redis (or some other place) and ignore the job if
it hasn't been long enough. In fact, you could write a separate
resque plugin to ensure a job of a particular nature (type + params)
is only ran once per X minutes. Assuming you are storing the
notifications somewhere other than just the params of the resque job,
this would probably be much simpler and would also cover you in the
case of a backed-up resque queue (rather than just jobs sitting in the
delayed queue).

On Oct 8, 2011, at 1:35 PM, Marc MacLeod
reply@reply.github.com
wrote:

Similar to resque-loner? A use-case here is I put in a delayed job to send a notification email 30 minutes from now. If another notification is added before the 30 minutes I don't want to add another send email delayed job. When the job is run it aggregates all the new notifications and sends them in one email.

Reply to this email directly or view it on GitHub:
#113

[marbemac]

Hmm ok. Would something like this at the end of the job work to remove any duplicates?

class SomeJob
def self.perform(user_id)
Resque.remove_delayed(self, user_id)
end
end

[bvandenbos]

No, I would not suggest tying it to resque-scheduler at all. Take a look at the discussion in this pull request: #52

In short, if you want a job to only one at most, once per X, preventing it at the resque-scheduler level is probably not the right place. It's fastest/easiest to just store the last time (or next time) you want a job to actually do work and just have all the rest skip the work. That way you can keep blindly enqueuing them (now or in the future) and the job will keep track of whether or not to actually perform the work. Again, this should be a pretty straight forward plugin to write if you wanted a more general solution.