You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it would be a simple and very useful feature if django-q could send signals at some point of its operation. I'm thinking of the following signals:
pre_enqueue: would be run in the tasks.async() function before the task is sent to the broker, and would receive the whole task object.
pre_execute: would be run by the worker before executing the function.
Those could be simple Django signals.
The reason I'm asking for this is I'm trying to implement a "singleton" task, a task that would guarantee only one (or zero) instance of itself in the queue. For that I store a lock in the cache when the task is enqueued and release it when the task is run. If a lock is found, the enqueue operation isn't done a second time, instead the previous id is return. I could wrap the async function or subclass the Async class but it's hard to do properly because function arguments are mixed with task options, and the function must remain pickleizable.
Having signals would make that much easier, I could lock and unlock in the cache using those signals, and just subclass Async to check for the lock in run().
The text was updated successfully, but these errors were encountered:
abompard
added a commit
to abompard/django-q
that referenced
this issue
Mar 3, 2017
I think it would be a simple and very useful feature if
django-q
could send signals at some point of its operation. I'm thinking of the following signals:pre_enqueue
: would be run in thetasks.async()
function before the task is sent to the broker, and would receive the whole task object.pre_execute
: would be run by the worker before executing the function.Those could be simple Django signals.
The reason I'm asking for this is I'm trying to implement a "singleton" task, a task that would guarantee only one (or zero) instance of itself in the queue. For that I store a lock in the cache when the task is enqueued and release it when the task is run. If a lock is found, the enqueue operation isn't done a second time, instead the previous
id
is return. I could wrap theasync
function or subclass theAsync
class but it's hard to do properly because function arguments are mixed with task options, and the function must remain pickleizable.Having signals would make that much easier, I could lock and unlock in the cache using those signals, and just subclass
Async
to check for the lock inrun()
.The text was updated successfully, but these errors were encountered: