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 decoratorLien vers cette rubrique#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: contrôle si la fonction Task accepte un objet TaskContext. Vaut False par défaut. Voir Contexte des tâches pour plus de détails.
Si la tâche définie n’est pas valable selon le moteur, une exception InvalidTask est générée.
Voir définition des tâches pour des exemples d’utilisation.
\nTaskLien vers cette rubrique#Représente une tâche à exécuter en arrière-plan. Les tâches doivent être définies par le décorateur func:task.
\nLes attributs de Task ne peuvent pas être modifiés. Voir :ref:modification des tâches <modifying-tasks>` pour plus de détails.
La priorité de Task. Les priorités doivent se situer entre -100 et 100, où un plus grand nombre signifie une priorité plus haute et va donc s’exécuter plus rapidement.
Le moteur doit avoir l’attribut supports_priority à True pour pouvoir utiliser cette fonctionnalité.
L’alias du moteur pour lequel la tâche Task doit être placée en file d’attente. Cela doit correspondre à un moteur défini dans BACKEND.
Le nom de la file d’attente à laquelle la tâche sera attribuée. Par défaut, c’est "default". Cela doit correspondre à une file d’attente définie dans QUEUES, sauf si QUEUES est défini à [].
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.
Le nom de la fonction décorée par task(). Ce nom n’est pas forcément unique.
Crée une nouvelle Task avec des valeurs par défaut modifiées. La tâche existante n’est pas touchée.
using permet de modifier les attributs suivants :
Voir modification des tâches pour des exemples d’utilisation.
\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.
\nLa variante async de enqueue.
Récupère un résultat à partir de son 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.
La variante async de 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.
\nContient des informations au sujet de l’erreur générée durant l’exécution de la tâche.
\nLa trace d’erreur (sous forme de chaîne) de l’exception générée lorsque la tâche a échoué.
\nLa classe d’exception générée lors de l’exécution de la tâche.
\nBackends 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\nConfiguration d’un moteur de tâches.
\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.
Notes de bas de page
\n\n