Open Stack

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 <rakhmerov at mirantis.com>
wrote:

> FYI
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
>
> Begin forwarded message:
>
> *From: *Renat Akhmerov <rakhmerov at mirantis.com>
> *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)" <
> openstack-dev at lists.openstack.org>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150902/a1738170/attachment.html>