Open Stack

If I understand the meaning of “join” function correctly then from user perspective this behavior in Mistral and Yaqluator is a bug because we’re joining two collections similar to how it works in SQL so the correct result should be:

[[1, 3], [2, 3]]

I.e. collection consisting of two collections where each element if the first one is combined with each element of the second one.

If so, we need to fix this in both Mistral and Yaqluator.


Alex, Stan, do you agree?

Renat Akhmerov
@Nokia

> On 28 Jun 2016, at 23:46, Elisha, Moshe (Nokia - IL) <moshe.elisha at nokia.com> wrote:
> 
> Hi,
> 
> Thank you for the kind words, Alexey.
> 
> I was able to reproduce your bug and I have also found the issue.
> 
> The problem is that we did not create the parser with the engine_options used in the yaql library by default when using the CLI.
> Specifically, the "yaql.limitIterators" was missing… I am not sure that this settings should have this affect but maybe the Yaql guys can comment on that.
> 
> If we will change yaqluator to use this setting it will mean that yaqluator will not be consistent with Mistral because Mistral is using YAQL without this engine option (If I use your example in a workflow, Mistral returns exactly like the yaqluator returns)
> 
> 
> Workflow:
> 
>> ---
>> version: '2.0'
>> 
>> test_yaql:
>>   tasks:
>>     test_yaql:
>>       action: std.noop
>>       publish:
>>         output_expr: <% [1,2].join([3], true, [$1, $2]) %>
> 
> Workflow result:
> 
> 
> [root at s53-19 ~(keystone_admin)]# mistral task-get-published 01d2bce3-20d0-47b2-84f2-7bd1cb2bf9f7
> {
>     "output_expr": [
>         [
>             1,
>             3
>         ]
>     ]
> }
> 
> 
> As Matthews pointed out, the yaqluator is indeed OpenSource and contributions are welcomed.
> 
> [1] https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2 <https://github.com/ALU-CloudBand/yaqluator/commit/e523dacdde716d200b5ed1015543d4c4680c98c2>
> 
> 
> 
> From: Dougal Matthews <dougal at redhat.com <mailto:dougal at redhat.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>>
> Date: Monday, 27 June 2016 at 16:44
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org>>
> Subject: Re: [openstack-dev] [mistral] [murano] [yaql] yaqluator bug
> 
> On 27 June 2016 at 14:30, Alexey Khivin <akhivin at gmail.com <mailto:akhivin at gmail.com>> wrote:
>> Hello, Moshe 
>> 
>> Tomorrow I discovered yaqluator.com <http://yaqluator.com/> for myself! Thanks for the useful tool!
>> 
>> But suddenly I was said that the expression 
>> [1,2].join([3], true, [$1, $2]) 
>> evaluated to [[1,3]] on the yaqluator
>> 
>> A the same time this expression evaluated right when I using raw yaql interpreter.
>> 
>> Could we fix this issue?
>> 
>> By the way, don't you want to make yaqluator opensource? If you would transfer yaqluator to Openstack Foundation, then  community will be able to fix such kind of bugs
> 
> It looks like it is open source, there is a link in the footer: https://github.com/ALU-CloudBand/yaqluator <https://github.com/ALU-CloudBand/yaqluator>
>  
>> 
>> Thank you!
>> Best regards, Alexey Khivin
>> 
>> 
>> 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160705/4977ab22/attachment.html>