[jboss-jira] [JBoss JIRA] (DROOLS-5280) List Filter expression returning single item and nested within arithmetic expression fails to evaluate

[Matteo Mortari (Jira)]

    [ https://issues.redhat.com/browse/DROOLS-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14065994#comment-14065994 ] 

Matteo Mortari commented on DROOLS-5280:
----------------------------------------

[~tracyhires] thank you for reporting but there is no bug, and I believe while creating this model a specific semantic feature of DMN FEEL expressions has been overlooked; in the below I will argument why there is no bug, I will give some technical AND Methodology suggestions to fix or better model the use-case, and I will finally close the ticket as no bug is actually found.

Feel free to re-open if anything was not addressed fully.

h2. There is no bug

You wrote:

{quote}the expression `addend + listOfStructure[field1="some value"].numberField`, where `field1="some value"` filters `listOfStructure` to a single item and `addend` and `numberField` are both non-null numbers, fails to evaluate{quote}

but this is not accurate.

Your actual expression is:

{code:java}
addend + Color Lookup[key=color].value
{code}

but {{Color Lookup[key=color].value}} is a projected feel:list<number> not a "single item"

In other words:

{noformat}
"filters" ? YES 
"to a single item" ? NO
{noformat}


Then, because in FEEL adding a number to a list is not a valid operation, per DMN specification a null value is returned for "Add" decision.
{code:java}
Example:
1 + [2, 3] = null
{code}
This part of the model is behaving per DMN specification.

Coming to the "GetItem" and "Add2" part of the model, again all is working as expected, simply decision "GetItem" is defining the expected result type and the singleton list of String_Tuple is coerced to String_Tuple.
This part of the model is behaving per DMN specification.

h2. A purely technical solution

Rewrite the current "Add" literal expression
from:
{code:java}
addend + Color Lookup[key=color].value
{code}

to:
{code:java}
addend + Color Lookup[key=color].value[1]
{code}

this way you explicitly model the fact that the lookup shall return only a single number as the second operand of the arithmetic sum.

h2. A Methodology solution

In my perspective, it was lacking in the original modeling the fact that a lookup was meaning to return a single instance.
I believe this could be best modeled by encapsulating the logic of the look-up in a BKM "function":
 !screenshot-1.png! 

This way HOW the lookup is actually performed is properly encapsulated in a BKM.

Further, in my perspective is best to make the expectation explicit while implementing the BKM, like so:
 !screenshot-2.png! 

Finally, the use of this BKM in the "Add" decision for instance, is very natural:
 !screenshot-3.png! 

As based on the BKM signature it is explicit it is a function that take a feel:string and return a String_Tuple, which is accordingly to your original problem statement.


I hope this clarifies and helps!

> List Filter expression returning single item and nested within arithmetic expression fails to evaluate
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-5280
>                 URL: https://issues.redhat.com/browse/DROOLS-5280
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>    Affects Versions: 7.34.0.Final, 7.36.0.Final
>            Reporter: Tracy Hires
>            Assignee: Matteo Mortari
>            Priority: Major
>         Attachments: MySpace_Relation.zip, screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> the expression `addend + listOfStructure[field1="some value"].numberField`, where `field1="some value"` filters `listOfStructure` to a single item and `addend` and `numberField` are both non-null numbers, fails to evaluate. It's possible to work around this by placing `listOfStructure[field1="some value"]` into a separate decision.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)