Forums

Jobs - "executeJob" vs "run"

Permalink
Just a gottcha which caught me out. Putting it here for anyone else.

The "run" method doesn't update the Job database table in any way whatsoever. So the job will run, but you wont get any updates to "jobLastRun" dates.

"executeJob" is the more robust method that behaves as you'd expect.
moth
 
Remo replied on at Permalink Reply
Remo
It's the other way round, run() is what you're supposed to use. executeJob updates the date and state and calls run() on the way doing that. Check this:
https://github.com/concrete5/concrete5/blob/master/web/concrete/core...
moth replied on at Permalink Reply
moth
Not sure I'm with you. run() most definitely isn't updating the job status for me.
Remo replied on at Permalink Reply
Remo
It most definitely does for me ;-)

Have you checked the code I've mentioned above? If you override executeJob, you'll also override the code which marks a job as executed. You can also see that the run() method is specified as "abstract", not implementing it would certainly be wrong..
moth replied on at Permalink Reply
moth
I'm doing this;

Loader::model("job");
$fetch_feed = Job::getByHandle('fetch_feed');
$fetch_feed->executeJob();


Which, as far I can tell, does exactly what I'd expect (and is what I see in the function).

- Mark the Job as running
- Try to run the job
- If it completes, mark as Completed.

If I do this;

Loader::model("job");
$fetch_feed = Job::getByHandle('fetch_feed');
$fetch_feed->run();


... I get zero updates to the Jobs database table. Nothing. But the job runs.
Remo replied on at Permalink Reply
Remo
Ah okay, now I get what you mean!

When you call the job yourself, you'll have to call "executeJob", but when you implement a job, you'll have to use the "run" method.

I think it's pretty rare that someone calls a job directly, but if they do, executeJob is the way to go