Hi,

I’d like to propose a few changes after transition to yaql 1.0:

We already moved from using “$.__execution” in DSL to "execution()” and from 
“$.__env” to “env()” where “execution()” and “env()" are registered yaql 
functions. We had to do it because double underscored are prohibited in the new 
yaql.


In the spirit of these changes I’m proposing a similar change for addressing 
task result in Mistral DSL.

Currently we have the syntax “$.task_name” that we can use in yaql expressions 
to refer to corresponding task result. The current implementation is of that is 
kind of tricky and, IMO, conceptually wrong because referencing this kind of 
key leads to DB read operation that’s requried to fetch task result (it may be 
big as megabytes so it can’t be stored in workflow context all the time. In 
other words, we create a dictionary with side effect and change the initial 
semantics of dictionary. Along with mentioned trickiness of this approach it’s 
not convenient, for example, to debug the code because we can accidentally 
cause a DB operation. 

So the solution I’m proposing is to have an explicit yaql function called “res” 
or “result” to extract task result.

res() - extracts the result of the current task, i.e. in “publish” clause.
res(‘task_name’) - extracts the result of the task with the specified name. Can 
also be used in “publish” clause, if needed

This approach seems more flexible (cause we can add any other functions w/o 
having to make significant changes in WF engine) and expressive because user 
won’t confuse $.task_name with addressing a regular workflow context variable.

Of course, this to some extent breaks backwards compatibility. But we already 
changed yaql version which was necessary anyway so it seems like a good time to 
do it.

I’d very much like to have your input on this.

Renat Akhmerov
@ Mirantis Inc.



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to