-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recurring/Scheduled/"Cron-like" Tasks #19
Comments
While waiting for this to be implemented, I created a quick class that will allow you to create a recurring job: https://gist.github.com/jesperborgstrup/93d943da96c653645b7d |
That's more or less what I had in mind. I personally don't want to limit recurring jobs by class alone, so the final implementation would need to be adjusted some to allow developers to override the identifier with something else, but otherwise, my suggestion would be to adopt this approach, and adjust it so it isn't in the job class, but in the library itself. Though it would also be good to support a more cron-like spec for intervals, probably in addition to a regular number-of-seconds approach. |
As something like this isn't yet implemented in PHP Resque Scheduler I am using your class @jesperborgstrup, thanks for that. However, from what I've read from your main notes:
So let's say I use those jobs to grab some information about a user somewhere on the Internet. I cannot schedule jobs for each user at the same time, because all users use the same class? Is that it? If so, why did you put that restriction and how can I bypass it? |
I guess you could remove the restriction, but do you really want to schedule a recurring job for each user? |
The
README
states that only theat
-like functionality is implemented, and thecron
-like functionality is planned for a future release. Upon investigation of how resque-scheduler works, it seems to rely on an external library to actually act as the cron portion, which then merely schedules tasks using theat
-like functionality actually built in.So my question - and this issue is more of a discussion starter than a bug report - is whether we want to implement this functionality in this manner, or if we wish to take a different approach that leverages the fact we're using Redis already anyway. I have an idea that I'd like to flesh out a bit before I propose it more formally, but I was curious if there were any other opinions already out there.
The text was updated successfully, but these errors were encountered: