Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[incubator-kie-issues#1543] Add the "id" of executed rules to the AfterEvaluateDecisionTableEvent #6127

Merged
merged 5 commits into from
Oct 18, 2024

Conversation

gitgabrio
Copy link
Contributor

Fixes apache/incubator-kie-issues#1543

How to retest this PR or trigger a specific build:
  • for pull request and downstream checks

    • Push a new commit to the PR. An empty commit would be enough.
  • for a full downstream build

    • for github actions job: add the label run_fdb
  • for Jenkins PR check only

@gitgabrio gitgabrio requested review from baldimir and yesamer October 16, 2024 12:18
@@ -153,7 +153,7 @@ protected List<List<UnaryTest>> objectToUnaryTestList(EvaluationContext ctx, Lis
*/
private static DTDecisionRule toDecisionRule(EvaluationContext mainCtx, FEEL embeddedFEEL, int index, List<?> rule, int inputSize) {
// TODO should be check indeed block of inputSize n inputs, followed by block of outputs.
DTDecisionRule dr = new DTDecisionRule( index );
DTDecisionRule dr = new DTDecisionRule( index, null );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gitgabrio If is legal to have a null id, why don't have a specific constructor with the index only?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point....
Well, this specific case seems sort-of corner case, since DecisionTableFunction has been removed (IINW) long time ago and we keep it for compatibility.
So, adding another constructor to DTDecisionRule would make it a little bit "ambiguous" just to cope for an exceptional case. From now on, DTDecisionRule should always have an "id" - and if the model does not define it, the id would be null- but it is slightly different then allowing instantiation completely without it: am I clear ? Does this make sense ?

*
* <p>
* http://www.apache.org/licenses/LICENSE-2.0
* <p>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gitgabrio Ooops

*
* <p>
* http://www.apache.org/licenses/LICENSE-2.0
* <p>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gitgabrio Ooops

Copy link
Contributor

@yesamer yesamer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved

Copy link
Contributor

@jomarko jomarko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for a PR @gitgabrio , I have single comment to the code, optional for sure.

decisionTable.getName(),
matchedIndexes );
}
List<DTDecisionRule> matchIndexes = items.matches();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I compare this with a very similar logic in DecisionTableImpl.java I would maybe stick also here to the variable name matches index of matchIndexes as DRDecisionRule contains more data than index.

Copy link
Contributor Author

@gitgabrio gitgabrio Oct 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HI @jomarko I agree and see your point.
Anyway all that part needs review, i.e.

  1. verify if that alphanetbased part is actually used anywhere
  2. double check the usage of that Indexed interface (from which the name matchIndexes came originally)
  3. verify/remove all code-duplication, eventually

@yesamer yesamer added the DMN label Oct 17, 2024
Copy link
Contributor

@jomarko jomarko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you for updates @gitgabrio

@gitgabrio
Copy link
Contributor Author

kogito-runtimes failure unrelated
apache_incubator-kie-kogito-runtimes/jbpm/jbpm-tests/src/test/java/org/jbpm/bpmn2/StandaloneBPMNProcessTest.java:407 | expected: 2 but was: 1

serverless-workflow-examples failure unrelated
mvn <args> -rf :serverless-workflow-python-quarkus

@gitgabrio gitgabrio merged commit f1307e1 into apache:main Oct 18, 2024
10 of 12 checks passed
@gitgabrio gitgabrio deleted the incubator-kie-issues#1543 branch October 18, 2024 08:31
rgdoliveira pushed a commit to rgdoliveira/drools that referenced this pull request Oct 24, 2024
…erEvaluateDecisionTableEvent (apache#6127)

* [incubator-kie-issues#1543] Add the "id" of executed rules to the AfterEvaluateDecisionTableEvent

* [incubator-kie-issues#1543] Fix TODO

* [incubator-kie-issues#1543] Fix license header

* [incubator-kie-issues#1543] Minor refactoring on unrelated test

* [incubator-kie-issues#1543] Fix as per PR review

---------

Co-authored-by: Gabriele-Cardosi <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

DMN - Add the "id" of executed rules to the AfterEvaluateDecisionTableEvent
4 participants