Issues

Issue #32 wontfix

Allow to schedule a provided Job-instance

Kevin Palm
created an issue

Currently it is not possible to have own Job-Classes: The Job-Instance is always created by the Scheduler.add_job method.

I think that it would be nicer if there was another function like add_raw_job that received the Job-Instance as an argument.

Implemented it would look something like this;

    def add_job(self, trigger, func, args, kwargs, jobstore='default', **options):
        job = Job(trigger, func, args or [], kwargs or {}, options.pop('misfire_grace_time', self.misfire_grace_time), options.pop('coalesce', self.coalesce), **options)
        return self.add_raw_job(job, trigger, func, args, kwargs, jobstore='default', **options)

    def add_raw_job(self, job, trigger, func, args, kwargs, jobstore='default', **options):
        if not self.running:
            self._pending_jobs.append((job, jobstore))
            logger.info('Adding job tentatively -- it will be properly '
                        'scheduled when the scheduler starts')
        else:
            self._real_add_job(job, jobstore, True)
        return job

BTW: I would make most arguments of Job-class optional (behalves trigger and func of course)

Comments (5)

  1. Alex Grönholm repo owner

    The Job class was never intended to be subclassed by users. Job stores create Job instances directly from stored data. What are you aiming at with this?

  2. Kevin Palm reporter

    I already have a class containing:

    1. the function to be executed
    2. all schedule information

    I wanted to avoid to create a new job-instance, but to use my class instead directly. (avoid to have to handle one more object)

    I know the benefit (in my case) isn't very big... (But others could perhaps want to implement some special job specific hings in 'compute_next_run_time' method... )

    (Even with jobstores, this feature could be feasible: Instead of using everywhere class 'Job', you could have a property 'apscheduler.jobClass' wich defaults to 'apscheduler.job.Job' but which could be overriden by the user if wanted)

  3. Alex Grönholm repo owner

    Why would they want to override compute_next_run_time? That's what triggers are for. This request is not feasible and frankly I don't see much point in it, at least given those arguments.

  4. Log in to comment