CODEWITHSUNDEEP
python-2.7apscheduler
Dan Lenski
Dan Lenski

Reputation: 79800

copying rather than modifying a job (APScheduler)

I'm writing a database-driven application with APScheduler (v3.0.0). Especially during development, I find myself frequently wanting to command a scheduled job to start running now without affecting its subsequent schedule.

It's possible to do this at job creation time, of course:

def dummy_job(arg):
  pass
sched.add_job(dummy_job, trigger='interval', hours=3, args=(None,))
sched.add_job(dummy_job, trigger=None, args=(None,))

However, if I already have a job scheduled with an interval or date trigger...

>>> sched.print_jobs()
Jobstore default:
   job1 (trigger: interval[3:00:00], next run at: 2014-08-19 18:56:48 PDT)

... there doesn't seem to be a good way to tell the scheduler "make a copy of this job which will start right now." I've tried sched.reschedule_job(trigger=None), which schedules the job to start right now, but removes its existing trigger.

There's also no obvious, simple way to duplicate a job object while preserving its args and any other stateful properties. The interface I'm imagining is something like this:

sched.dup_job(id='job1', new_id='job2')
sched.reschedule_job('job2', trigger=None)

Clearly, APScheduler already contains an internal mechanism to copy job objects since repeated calls to get_job don't return the same object (that is, (sched.get_job(id) is sched.get_job(id))==False).

Has anyone else come up with a solution here? I'm thinking of posting a suggestion on the developers' site if not.

Upvotes: 0

Views: 1077

Answers (1)

Alex Grönholm
Alex Grönholm

Reputation: 5911

As you've probably figured out by now, that phenomenon is caused by the job stores instantiating jobs on the fly based on data loaded from the back end. To run a copy of a job immediately, this should do the trick:

job = sched.get_job(id)
sched.add_job(job.func, args=job.args, kwargs=job.kwargs)

Upvotes: 2

Related Questions