[Red Hat JIRA] (DROOLS-5913) [DMN Designer] Improving UX when Decision Table is relying on not updated data.
by Yeser Amer (Jira)
Yeser Amer created DROOLS-5913:
----------------------------------
Summary: [DMN Designer] Improving UX when Decision Table is relying on not updated data.
Key: DROOLS-5913
URL: https://issues.redhat.com/browse/DROOLS-5913
Project: Drools
Issue Type: Enhancement
Reporter: Yeser Amer
Assignee: Guilherme Gomes
We should find a way to improve User Experience in the case a Decision Table is relying on Data Type which was modified by the user.
Original Message:
{noformat}
TL;DR a modification of an Object (aka Structure) in the Data Model does not get reflected in the DMN Model.
Maybe someone can point out the error in the following scenario.
(1) Using the DMN editor in BC RHPAM.7.9 I defined the "Ve" Object (aka Structure) and the "Ve_data1" simple variable in the Data Model as custom data types
(2) "Ve", named as "Vehicle", was used as data input to a DMN model and a decision was defined backed by a decision table
(3) when the decision table was first created the columns for the "Vehicle" attributes were created as individual columns.
(4) Modified the "Ve" structure by removing some attributes
(5) The deleted attributes are still available in the decision table.
I have two issues in this scenario.
(I1) Step (3). By creating the columns as individual columns of the "Vehicle" variable in the decision table any sense between them belonging to the "Ve" structure is lost. Furthermore the decision table allows for changing the data type of the columns despite the fact that these belong(?) to the "Ve" object.
(I2) Step (5). I was expecting that by modifying the columns in the data structure that change would be visible in the decision table as well. Yes, a warning is generated, but it is cryptic, lost in a table full of equally cryptic messages and no visual indication of the actual problem in the decision table. I can check the messages and find out what is going on, but explaining this to my customer proved to be quite a challenge.
We are still targeting DMN to business analysts I presume.
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (DROOLS-5697) Make exec model's groupBy() composable
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5697?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5697:
--------------------------------
Sprint: 2020 Week 52-03 (from Dec 21) (was: 2020 Week 49-51 (from Nov 30))
> Make exec model's groupBy() composable
> --------------------------------------
>
> Key: DROOLS-5697
> URL: https://issues.redhat.com/browse/DROOLS-5697
> Project: Drools
> Issue Type: Enhancement
> Components: executable model
> Affects Versions: 7.44.0.Final
> Reporter: Lukáš Petrovický
> Assignee: Mario Fusco
> Priority: Major
>
> In some of the OptaPlanner examples, we have Constraint Streams like this:
> {code:java}
> .groupBy(ProcessAssignment::getService, count())
> .groupBy(Service::getTag, max((service, count) -> count))
> {code}
> This will:
> - Take all ProcessAssigment instances.
> - Count all such instances which run on the same Service.
> - Out of all the pairs of (service, count) find the maximum count where the services share the same Tag.
> This is an example of groupBy composition. Currently, we implement it with the old, inefficient groupBy. That implementation looks something like this:
> {noformat}
> when
> $tuples: List<Tuple<Service, Integer>> from accumulate(
> $p: ProcessAssignment(),
> ...
> groupBy(ProcessAssignment::getService, count())
> )
> $tuples2: List<Tuple<String, Integer>> from accumulate(
> $tuple: Tuple<Service, Integer> from $tuples,
> ...
> groupBy(Service::getTag, max($tuple._2))
> )
> $result: Tuple<String, Integer> from $tuples2
> then
> System.out.println($result);
> end
> {noformat}
> We'd like the new groupBy construct to be capable of composition instead.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (DROOLS-5866) Move back core tests from drools-mvel
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5866?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5866:
---------------------------------
Description:
see
[https://github.com/kiegroup/drools/tree/master/drools-mvel/src/test/java/...]
[https://github.com/kiegroup/drools/blob/master/drools-mvel/src/test/java/...]
https://github.com/kiegroup/drools/blob/master/drools-mvel/src/test/java/...
AlphaNodeTest, RightTupleIndexHashTableTest, RightTupleIndexHashTableIteratorTest etc are not testing MVEL they happened to use MVEL, and can be replaced by a lambda.
we need to audit all the tests there, make sure we keep things specifically meant to test MVEL itself, and not a test of something else that happened to use MVEL.
was:
see
[https://github.com/kiegroup/drools/tree/master/drools-mvel/src/test/java/...]
[https://github.com/kiegroup/drools/blob/master/drools-mvel/src/test/java/...]
https://github.com/kiegroup/drools/blob/master/drools-mvel/src/test/java/...
> Move back core tests from drools-mvel
> -------------------------------------
>
> Key: DROOLS-5866
> URL: https://issues.redhat.com/browse/DROOLS-5866
> Project: Drools
> Issue Type: Bug
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> see
>
> [https://github.com/kiegroup/drools/tree/master/drools-mvel/src/test/java/...]
>
> [https://github.com/kiegroup/drools/blob/master/drools-mvel/src/test/java/...]
>
> https://github.com/kiegroup/drools/blob/master/drools-mvel/src/test/java/...
> AlphaNodeTest, RightTupleIndexHashTableTest, RightTupleIndexHashTableIteratorTest etc are not testing MVEL they happened to use MVEL, and can be replaced by a lambda.
> we need to audit all the tests there, make sure we keep things specifically meant to test MVEL itself, and not a test of something else that happened to use MVEL.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months