获取特定用户的挂起任务数量

时间:2022-12-21 02:17:05

In one of my applications i want to limit users to make a only a specific number of document conversion each calendar month and want to notify them of the conversions they've made and number of conversions they can still make in that calendar month.

在我的一个应用程序中,我希望限制用户在每个日历月只进行特定数量的文档转换,并希望通知他们所进行的转换以及在那个日历月仍然可以进行的转换的数量。

So I do something like the following.

我这样做。

class CustomUser(models.Model):
    # user fields here

    def get_converted_docs(self):
       return self.document_set.filter(date__range=[start, end]).count()

    def remaining_docs(self):
        converted = self.get_converted_docs()
        return LIMIT - converted

Now, document conversion is done in the background using celery. So there may be a situation when a conversion task is pending, so in that case the above methods would let a user make an extra conversion, because the pending task is not being included in the count.

现在,文档转换是在后台使用芹菜完成的。因此,可能会出现转换任务挂起的情况,所以在这种情况下,上面的方法会让用户进行额外的转换,因为挂起任务不包含在计数中。

How can i get the number of tasks pending for a specific CustomUser object here ??

如何在这里获得特定CustomUser对象的待完成任务数量?

update

ok so i tried the following:

好吧,我尝试了以下方法:

from celery.task.control import inspect

def get_scheduled_tasks():
    tasks = []
    scheduled = inspect().scheduled()
    for task in scheduled.values()
        tasks.extend(task)
    return tasks

This gives me a list of scheduled tasks but now all the values are unicode for the above mentioned task args look like this:

这给了我一个计划任务列表,但是现在所有的值都是unicode的,上面提到的任务args是这样的:

u'args': u'(<Document: test_document.doc>, <CustomUser: Test User>)'

is there a way these can be decoded back to original django objects so that i can filter them ?

有没有一种方法可以将它们解码回原来的django对象,这样我就可以过滤它们了?

1 个解决方案

#1


2  

Store the state of your documents somewhere else, don't inspect your queue. Either create a seperate model for that, or eg. have a state on your document model, at least independently from your queue. This should have several advantages:

将文档的状态存储在其他地方,不要检查队列。要么创建一个seperate模型,要么。文档模型上有一个状态,至少独立于队列。这应该有几个优点:

  • Inspecting the queue might be expensive - also depending on the backend for that. And as you see it can also turn out to be difficult.
  • 检查队列可能很昂贵——这也取决于后端。正如你所看到的,它也会变得很困难。
  • Your queue might not be persistent, if eg. your server crashes and use something like Redis you would loose this information, so it's a good thing to have a log somewhere else to be able to reconstruct the queue)
  • 您的队列可能不会持久,如果。你的服务器崩溃了,使用了Redis之类的东西你会丢失这些信息,所以最好在别的地方有一个日志可以重建队列)

#1


2  

Store the state of your documents somewhere else, don't inspect your queue. Either create a seperate model for that, or eg. have a state on your document model, at least independently from your queue. This should have several advantages:

将文档的状态存储在其他地方,不要检查队列。要么创建一个seperate模型,要么。文档模型上有一个状态,至少独立于队列。这应该有几个优点:

  • Inspecting the queue might be expensive - also depending on the backend for that. And as you see it can also turn out to be difficult.
  • 检查队列可能很昂贵——这也取决于后端。正如你所看到的,它也会变得很困难。
  • Your queue might not be persistent, if eg. your server crashes and use something like Redis you would loose this information, so it's a good thing to have a log somewhere else to be able to reconstruct the queue)
  • 您的队列可能不会持久,如果。你的服务器崩溃了,使用了Redis之类的东西你会丢失这些信息,所以最好在别的地方有一个日志可以重建队列)