[
https://issues.redhat.com/browse/DROOLS-5280?page=com.atlassian.jira.plug...
]
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)