The Task framework provides the contract and plumbing for background work, not\nthe engine that runs it. The Tasks API defines how work is described, queued,\nand tracked, but leaves actual execution to external infrastructure.
\ntask decoratorLink to this heading#The @task decorator defines a Task instance. This has the\nfollowing optional arguments:
priority: Sets the priority of the Task. Defaults\nto 0.
queue_name: Sets the queue_name of the Task.\nDefaults to "default".
backend: Sets the backend of the Task. Defaults to\n"default".
takes_context: Controls whether the Task function accepts a\nTaskContext. Defaults to False. See Task context for details.
If the defined Task is not valid according to the backend,\nInvalidTask is raised.
See defining tasks for usage examples.
\nTaskLink to this heading#Represents a Task to be run in the background. Tasks should be defined\nusing the task() decorator.
Attributes of Task cannot be modified. See modifying Tasks for details.
The priority of the Task. Priorities must be between -100 and 100,\nwhere larger numbers are higher priority, and will be run sooner.
The backend must have supports_priority set to True to use\nthis feature.
The alias of the backend the Task should be enqueued to. This must\nmatch a backend defined in BACKEND.
The name of the queue the Task will be enqueued on to. Defaults to\n"default". This must match a queue defined in\nQUEUES, unless\nQUEUES is set to [].
The earliest time the Task will be executed. This can be a\ntimedelta, which is used relative to the\ncurrent time, a timezone-aware datetime,\nor None if not constrained. Defaults to None.
The backend must have supports_defer set to True to use\nthis feature. Otherwise,\nInvalidTask is raised.
The name of the function decorated with task(). This name is not\nnecessarily unique.
Creates a new Task with modified defaults. The existing Task is\nleft unchanged.
using allows modifying the following attributes:
See modifying Tasks for usage examples.
\nEnqueues the Task to the Task backend for later execution.
Arguments are passed to the Task's function after a round-trip\nthrough a json.dumps()/json.loads() cycle. Hence, all\narguments must be JSON-serializable and preserve their type after the\nround-trip.
If the Task is not valid according to the backend,\nInvalidTask is raised.
See enqueueing Tasks for usage examples.
\nThe async variant of enqueue.
Retrieves a result by its id.
\nIf the result does not exist, TaskResultDoesNotExist is raised. If the\nresult is not the same type as the current Task,\nTaskResultMismatch\nis raised. If the backend does not support get_result(),\nNotImplementedError is raised.
The async variant of get_result.
Contains context for the running Task. Context only passed to a\nTask if it was defined with takes_context=True.
Attributes of TaskContext cannot be modified.
The TaskResult currently being run.
The number of the current execution attempts for this Task, starting at\n1.
\nAn Enum representing the status of a TaskResult.
The Task has just been enqueued, or is ready to be executed\nagain.
The Task is currently being executed.
The Task raised an exception during execution, or was unable\nto start.
The Task has finished executing successfully.
The TaskResult stores the information about a specific execution of a\nTask.
Attributes of TaskResult cannot be modified.
The Task the result was enqueued for.
A unique identifier for the result, which can be passed to\nTask.get_result().
The format of the id will depend on the backend being used. Task result\nids are always strings less than 64 characters.
\nSee Task results for more details.
\nThe status of the result.
The time when the Task was enqueued.
The time when the Task began execution, on its first attempt.
The time when the most recent Task run began execution.
The time when the Task finished execution, whether it failed or\nsucceeded.
The backend the result is from.
\nA list of TaskError instances for the errors raised as part of\neach execution of the Task.
The return value from the Task function.
If the Task did not finish successfully, ValueError is\nraised.
See return values for usage examples.
\nRefresh the result's attributes from the queue store.
\nThe async variant of TaskResult.refresh().
Whether the Task has finished (successfully or not).
The number of times the Task has been run.
\nIf the task is currently running, it does not count as an attempt.
\nThe ids of the workers which have executed the Task.
\nContains information about the error raised during the execution of a\nTask.
The traceback (as a string) from the raised exception when the Task\nfailed.
The exception class raised when executing the Task.
Backends handle how Tasks are stored and executed. All backends share a common\ninterface defined by BaseTaskBackend, which specifies the core methods for\nenqueueing Tasks and retrieving results.
BaseTaskBackend is the parent class for all Task backends.
A dictionary of extra parameters for the Task backend. These are\nprovided using the OPTIONS setting.
Task backends which subclass BaseTaskBackend should implement this\nmethod as a minimum.
When implemented, enqueue() enqueues the task, a Task\ninstance, for later execution. args are the positional arguments\nand kwargs are the keyword arguments to be passed to the task.\nReturns a TaskResult.
The async variant of BaseTaskBackend.enqueue().
Retrieve a result by its id. If the result does not exist,\nTaskResultDoesNotExist is raised.
If the backend does not support get_result(),\nNotImplementedError is raised.
The async variant of BaseTaskBackend.get_result().
Validates whether the provided Task is able to be enqueued using\nthe backend. If the Task is not valid,\nInvalidTask\nis raised.
Some backends may not support all features Django provides. It's possible to\nidentify the supported functionality of a backend, and potentially change\nbehavior accordingly.
\nWhether the backend supports enqueueing Tasks to be executed after a\nspecific time using the run_after attribute.
Whether the backend supports enqueueing async functions (coroutines).
\nWhether the backend supports retrieving Task results from another\nthread after they have been enqueued.
Whether the backend supports executing Tasks as ordered by their\npriority.
The below table notes which of the built-in backends support which features:
\n\nDjango includes only development and testing backends. These support local\nexecution and inspection, for production ready backends refer to\nConfiguring a Task backend.
\nThe immediate backend executes Tasks\nimmediately, rather than in the background.
\nThe dummy backend does not execute enqueued\nTasks. Instead, it stores task results for later inspection.
\nA list of results for the enqueued Tasks, in the order they were\nenqueued.
\nClears the list of stored results.
\nRaised when the Task attempting to be enqueued\nis invalid.
Raised when the requested BaseTaskBackend is invalid.
Raised by get_result()\nwhen the provided result_id does not exist.
Raised by get_result() when the provided\nresult_id is for a different Task than the current Task.
脚注
\n\n