Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Docs to include direct access to DjangoJob model #74

Closed
irvinSing opened this issue May 28, 2020 · 1 comment
Closed

Update Docs to include direct access to DjangoJob model #74

irvinSing opened this issue May 28, 2020 · 1 comment

Comments

@irvinSing
Copy link

Using:
python version: Python 3.6.8
django version: 2.2.4

Not sure if it's actually documented anywhere, couldn't find it myself, but i managed to access the model directly by:

from django_apscheduler.jobstores import DjangoJob

obj = DjangoJob.objects.get(name=job_id)
obj.delete()

Reason that i had to do the above is because i wasn't able to remove the job by calling scheduler.remove_job('job_id').
This is despite the fact that i could clearly see the scheduled job in the Django admin interface with the 'name' field equivalent to 'job_id'.
However, if i call scheduler.get_jobs() or scheduler.print_jobs(), they show nothing at all.

I stored the 'job_id' separately in a different model using text field and extracted this from the separate model to input into the remove_job function. Not sure if this could have affected anything.. i doubt so.

In any case, i was able to delete the job directly by accessing the Django Job model directly.

Think this would be helpful information for anyone encountering difficulties removing job for any reason.

@jcass77
Copy link
Owner

jcass77 commented Jul 18, 2020

django_apscheduler uses regular Django models and all of the standard Django ORM features are available - we unfortunately do not have formally structured documentation available at the moment where we can drill down to this level of detail.

I can't think of a reason why remove_job would not have worked for you, but it is possible that #79 could have muted some error condition without making you aware of it.

@jcass77 jcass77 closed this as completed Jul 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants