<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi,<div class=""><br class=""></div><div class="">I’d like to propose a few changes after transition to yaql 1.0:</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">In the spirit of these changes I’m proposing a similar change for addressing task result in Mistral DSL.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">So the solution I’m proposing is to have an explicit yaql function called “res” or “result” to extract task result.</div><div class=""><br class=""></div><div class=""><b class="">res()</b> - extracts the result of the current task, i.e. in “publish” clause.</div><div class=""><b class="">res(‘task_name’)</b> - extracts the result of the task with the specified name. Can also be used in “publish” clause, if needed</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I’d very much like to have your input on this.</div><div class=""><br class=""></div><div class=""><div class="">
<div class="">Renat Akhmerov</div><div class="">@ Mirantis Inc.</div><div class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""></div></body></html>