Feature request: Implement soft deletion on remove_job, to save DjangoJobExecution

[andrewkoltsov]

Implement soft deletion on remove_job, to save DjangoJobExecution

Expected behavior
After execution "date" job result of this execution stays in DjangoJobExecution table.

[jcass77]

We could perhaps introduce a DjangoJob.is_removed BooleanField that is set when a job is removed by the scheduler via remove_job. This will also distinguish removed jobs from paused jobs (that just have their next_run_time set to None).

Another aspect to consider is implementing a custom model manager that provides something like an available_jobs convenience method for selecting and excluding jobs that have is_removed=True.

[CharleeSF]

I think this would also solve my issue that I get a FOREIGN KEY error when django-apscheduler tries to make a DjangoJobExecution object for the first time even though my job has already been removed by apscheduler..

[jcass77]

I think this would also solve my issue that I get a FOREIGN KEY error when django-apscheduler tries to make a DjangoJobExecution object for the first time even though my job has already been removed by apscheduler..

That should already be fixed as part of #116 and #121. Maybe try checking out the master branch to see if that works for you.

[jcass77]

One issue with implementing a 'soft delete' feature like this is that, if a job is created that has the same name but vastly different semantic meaning and functionality than a previously deleted job, then linking the old DjangoJobExecution records to the new job might not make sense.

From a user perspective it will seem like this brand new job has in fact been run many times in the past, even though it was just created.

Enforcing unique and non-repeating job names might go some way towards solving the above, but placing the burden of having to continuously come up with creative job names on the user is probably not ideal.

Alternatively, changing the Django models so that DjangoJob uses a sequential number as its ID / primary key might solve the above, but then we have the inverse problem of old DjangoJobExecutions not being linked to semantically the same job when it is re-created again.

Bottom line: how do we know which historical DjangoJobExecutions to link to which DjangoJobs if the user is allowed to re-use job names?

[lvelvee]

Perhaps adding a version field of DjangoJob would be the ideal option. We can determine the version number of a job function by hashing its source code.