Hi, I also thought about that recently. So, I absolutely agree with this proposal. It would be nice to see this feature in Liberty.
On Wed, Sep 2, 2015 at 2:17 PM, Renat Akhmerov <[email protected]> wrote: > FYI > > Renat Akhmerov > @ Mirantis Inc. > > > > Begin forwarded message: > > *From: *Renat Akhmerov <[email protected]> > *Subject: **[openstack-dev][mistral][yaql] Addressing task result using > YAQL function* > *Date: *2 Sep 2015 17:16:27 GMT+6 > *To: *"OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > > 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. > > > > > -- Best Regards, Nikolay
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
