Jump to: navigation, search

TaskFlow/Task Arguments and Results

< TaskFlow
Revision as of 09:00, 23 August 2013 by Ivan Melnikov (talk | contribs) (wrote down what i think)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Step 0: rename __call__ to execute

Just do that, __call__ looks too magical.

Required task arguments

Required arguments MUST be passed to task when it is executed, as execute method arguments.

Required arguments list should be inferred from execute method signature, like we already do for @task decorator.

We also need provide a way to override it, to make adaptors like FunctorTask possible.

Task results

Task result is what task returns from execute method. It is saved in persistence layer with task details and is passed to revert method when/if task is reverted.

To map result of already run task to task arguments, we must name task results This names are used as a key to storage ('memory' in TaskMachine terms) access

But we can't infer name from task signature, result naming should be explicit. To make solution more symmetric to inferring names from signature, we propose to use decorator on execute method for that.

For example:

   class MyTask(task.Task):
       @decorators.returns('foo', 'bar', 'baz'):
       def execute(self, context, spam, eggs):
           return 4, 8, 15  # 23 42

This required arguments are context, spam and eggs; it returns three values: foo, bar and baz. From it's implementation it is easy to see that foo will be equal to 4, bar to 8 and baz to 15.

Again, we need provide a way to override it, to make adaptors like FunctorTask possible.

Argument and result rebinding

It is sometimes useful to save task result with name other then specified in it. This can be a part of flow definition.

FIXME: short example with good explanation.

Optional task arguments

Task gets optional arguments as keyword arguments to execute (if task wants optional arguments, **kwargs should be added to execute argument list.

There is no need to specify what optional arguments task accepts, also it definitely worth to document them.

Which optional arguments are passed to task is specified in flow definition, in the same way as it is done for argument rebinding: add extra arguments to list or dict and these argument will be fetched from storage and passed to execute as keyword arguments.

FIXME: short example with good explanation.