Package: django-aps-register
Django APScheduler RegisterAPSchedulerregister forDjango.Installationpipinstalldjango-aps-registerQuick startAdddjango_apschedulerto yourINSTALLED_APPSsetting like this:INSTALLED_APPS=(# ..."django_apscheduler",)django-apscheduler comes with sensible configuration defaults out of the box. The defaults can be overridden by adding
the following settings to your Djangosettings.pyfile:# Format string for displaying run time timestamps in the Django admin site. The default# just adds seconds to the standard Django format, which is useful for displaying the timestamps# for jobs that are scheduled to run on intervals of less than one minute.## See https://docs.djangoproject.com/en/dev/ref/settings/#datetime-format for format string# syntax details.APSCHEDULER_DATETIME_FORMAT="N j, Y, f:s a"# Maximum run time allowed for jobs that are triggered manually via the Django admin site, which# prevents admin site HTTP requests from timing out.## Longer running jobs should probably be handed over to a background task processing library# that supports multiple background worker processes instead (e.g. Dramatiq, Celery, Django-RQ,# etc. See: https://djangopackages.org/grids/g/workers-queues-tasks/ for popular options).APSCHEDULER_RUN_NOW_TIMEOUT=25# SecondsRunpython manage.py migrateto create the django_apscheduler models.Add acustom Django management commandto your project
that schedules the APScheduler jobs and starts the scheduler:# runapscheduler.pyimportloggingfromdjango.confimportsettingsfromapscheduler.schedulers.blockingimportBlockingSchedulerfromapscheduler.triggers.cronimportCronTriggerfromdjango.core.management.baseimportBaseCommandfromdjango_apscheduler.jobstoresimportDjangoJobStorefromdjango_apscheduler.modelsimportDjangoJobExecutionfromdjango_apschedulerimportutillogger=logging.getLogger(__name__)defmy_job():# Your job processing logic here...pass# The `close_old_connections` decorator ensures that database connections, that have become# unusable or are obsolete, are closed before and after your job has run. You should use it# to wrap any jobs that you schedule that access the Django database in any way.@util.close_old_connectionsdefdelete_old_job_executions(max_age=604_800):"""This job deletes APScheduler job execution entries older than `max_age` from the database.It helps to prevent the database from filling up with old historical records that are nolonger useful.:param max_age: The maximum length of time to retain historical job execution records.Defaults to 7 days."""DjangoJobExecution.objects.delete_old_job_executions(max_age)classCommand(BaseCommand):help="Runs APScheduler."defhandle(self,*args,**options):scheduler=BlockingScheduler(timezone=settings.TIME_ZONE)scheduler.add_jobstore(DjangoJobStore(),"default")scheduler.add_job(my_job,trigger=CronTrigger(second="*/10"),# Every 10 secondsid="my_job",# The `id` assigned to each job MUST be uniquemax_instances=1,replace_existing=True,)logger.info("Added job 'my_job'.")scheduler.add_job(delete_old_job_executions,trigger=CronTrigger(day_of_week="mon",hour="00",minute="00"),# Midnight on Monday, before start of the next work week.id="delete_old_job_executions",max_instances=1,replace_existing=True,)logger.info("Added weekly job: 'delete_old_job_executions'.")try:logger.info("Starting scheduler...")scheduler.start()exceptKeyboardInterrupt:logger.info("Stopping scheduler...")scheduler.shutdown()logger.info("Scheduler shut down successfully!")The management command defined above should be invoked via./manage.py runapschedulerwhenever the webserver serving
your Django application is started. The details of how and where this should be done is implementation specific, and
depends on which webserver you are using and how you are deploying your application to production. For most people
this should involve configuring asupervisorprocess of sorts.Register any APScheduler jobs as you would normally. Note that if you haven't setDjangoJobStoreas the'default'job store, then you will need to includejobstore='djangojobstore'in yourscheduler.add_job()calls.Advanced usagedjango-apscheduler assumes that you are already familiar with APScheduler and its proper use. If not, then please head
over to the project page and have a look through
theAPScheduler documentation.It is possible to make use
ofdifferent types of schedulersdepending on your environment and use case. If you would prefer running aBackgroundSchedulerinstead of using aBlockingScheduler, then you should be aware that using APScheduler with uWSGI requires some additionalconfiguration stepsin
order to re-enable threading support.Supported databasesPlease take note of the list of databases that
areofficially supported by Django. django-apscheduler
probably won't work with unsupported databases like Microsoft SQL Server, MongoDB, and the like.Database connections and timeoutsdjango-apscheduler is dependent on the standard Django
databaseconfiguration settings. These settings,
in combination with how your database server has been configured, determine how connection management will be performed
for your specific deployment.Theclose_old_connectionsdecorator should be applied to APScheduler jobs that require database access. Doing so
ensures that Django'sCONN_MAX_AGEconfiguration setting is enforced before and after your job is run. This mirrors the standard Django functionality of
doing the same before and after handling each HTTP request.If you still encounter any kind of 'lost database connection' errors then it probably means that:Your database connections timed out in the middle of executing a job. You should probably consider incorporating a
connection pooler as part of your deployment for more robust database connection management
(e.g.pgbouncerfor PostgreSQL, or the equivalent for other DB platforms).Your database server has crashed / been restarted.
Djangowill not reconnect automaticallyand you need to re-start django-apscheduler as well.Common footgunsUnless you have a very specific set of requirements, and have intimate knowledge of the inner workings of APScheduler,
you really shouldn't be usingBackgroundScheduler. Doing so can lead to all sorts of temptations like:Firing up a scheduler inside of a Django view:this will most likely cause more than one scheduler to run
concurrently and lead to jobs running multiple times (see the above introduction to this README for a more thorough
treatment of the subject).Bootstrapping a scheduler somewhere else inside your Django application: it feels like this should solve the
problem mentioned above and guarantee that only one scheduler is running. The downside is that you have just delegated
the management of all of your background task processing threads to whatever webserver you are using (Gunicorn, uWSGI,
etc.). The webserver will probably kill any long-running threads (your jobs) with extreme prejudice (thinking that
they are caused by misbehaving HTTP requests).Relying onBlockingSchedulerforces you to run APScheduler in its own dedicated process that is not handled or
monitored by the webserver. The example code provided inrunapscheduler.pyabove is a good starting point.Project resources