Agree, with one detail: make it explicit - task(task_name).
res - we often see folks confused by result of what (action, task, workflow) although we cleaned up our lingo: action-output, task-result, workflow-output…. but still worth being explicit. And full result is being thought as the root context $. Publishing to global context may be ok for now, IMO. DZ> On Sep 2, 2015, at 4:16 AM, Renat Akhmerov <[email protected]> wrote: > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
