Reputation: 48503
I am accustomed from PHP to set up CRON on the URL address, that I want to run automatically in a time interval.
Now I try to set up the Schedular add-on at Heroku and I have a little problem - I created the file lib/tasks/scheduler.rake
and in admin section on Heroku set up everything what is possible, but:
I am a bit confused, how it all works - for example, these lines are in lib/tasks/scheduler.rake
:
desc "This task is called by the Heroku scheduler add-on"
task :update_feed => :environment do
puts "Updating feed..."
NewsFeed.update
puts "done."
end
task :send_reminders => :environment do
User.send_reminders
end
What mean the task task :update_feed? In the set up hour will be run this action? But this is action in which controller? For example, what if I would need to run every day the action my_action
in the controller home
? I should set up there again only my_action
instead update_feed
?
Upvotes: 0
Views: 1092
Reputation: 10701
With a cron to call an http action, such as using curl or wget, you are scheduling an http request, and the http request then results in the php action running, and in that action's code you have some work/logic that occurs.
With heroku scheduler, you are skipping all the http request stuff and action stuff, and can put the logic/work into the rake task directly (or put it in a regular ruby class or model and invoke that from the task body).
This works because the rake task is loading up the full rails environment (the :environment dependency part of the task definition does this), so inside the rake task body, you have access to your rails app models, required gems, application configuration, everything - just like inside a controller or model class in rails.
What's also nice, if you are on cedar, is that the scheduler invokes tasks in a one-off dynamo instance, so your app's main dynamo is not occupied by a task run by the scheduler, which is not the case when you use the cron -> http request -> controller action pattern.
If you tell me more about what you are trying to do, I can give more specific advice, but in general I usually have the task's logic defined in a plain ruby class in the lib directory, or as a class method on a model, and that is what would be called from the task body (as in the example code you cite above).
Upvotes: 2