-
Notifications
You must be signed in to change notification settings - Fork 51
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
Delete job functionality #48
Comments
Great suggestions, thank you! You're right, probably both would be useful in different contexts/use cases. I agree that proper input validation and error handling are very important when implementing this feature. |
Thinking of use-cases maybe the expiry time could be split into several scenarios?
|
Yeah, that makes sense. Good ideas 👍 I might want to only expire a certain class of jobs though, so manual control as I suggested would still be very good. |
Wait... was this implemented? Kinda looking for such a function but it appears I'll have to delete the job somehow else Seems the only way to delete the job is by creating (\Resque\Redis::instance())->del("resque:job:jobId") but job still somehow "remains in memory" after scanning for them with |
So, we have a default expiry for jobs, but I have a use-case where I want to get rid of data as quick as possible for security reasons. I want to handle sensitive data with jobs but once it's processed I want to get rid of the payload as quickly as possible.
We have this issue #34 which kinda ties into this a bit.
I propose two options:
delete()
function toJob.php
which would have the job delete itself from redis, something like$this->redis->del(self::redisKey($this));
setExpiry(int seconds)
function toJob.php
which can manually set the expiry time. This could indirectly be used to delete things by setting the seconds to0
I think. e.g.$this->redis->expire(self::redisKey($this), seconds);
(we'd need to validate the inputs here), in addition this function could replace this usage of$this->redis->expire
inJob.php
I think both are good options, we could implement them both. They cover different use-cases.
Thoughts?
The text was updated successfully, but these errors were encountered: