Uploaded image for project: 'Drools'
  1. Drools
  2. DROOLS-6064

Inconsistent behavior when accumulate function returns null



    • Bug
    • Resolution: Done
    • Major
    • 7.53.0.Final
    • 7.50.0.Final
    • core engine
    • None
    • 2021 Week 10-12 (from Mar 8), 2021 Week 13-15 (from Mar 29)
    • 5
    • Undefined
    • NEW
    • NEW
    • ---
    • ---


      When you use accumulate and no fact matches, the behaviors are different depending on accumulate functions:

          rule "accumualte_rule_min"
              accumulate( target : Target( target.getText() == "XXX" ),
                          $min : min( target.getNumber1() ) )
              System.out.println("***** accumualte_rule_min: $min = " + $min);

      min() : IntegerMinAccumulateFunction -> returns null if no fact matches
      max() : IntegerMaxAccumulateFunction -> returns null if no fact matches
      ave() : AverageAccumulateFunction -> returns null if no fact matches

      -> If the result is null, the rule won't fire.


      count() : CountAccumulateFunction -> returns 0 if no fact matches
      sum() : IntegerSumAccumulateFunction -> returns 0 if no fact matches

      -> result is not null. So the rule is fired.

      min(), max() : When you have multiple functions in accumulate, MultiAccumulate is used. This returns Object[] which contains multiple results. In this case, result = Object[2] which is [null, null].


      -> In this case, the result is not null. So the rule is fired with these "null" results.

      This JIRA is to make it consistent.

      Mark Proctor wrote:

      I always thought the behaviour was to propagate, regardless of the result of the accumulation. If there is a left input into the accumulation node, an accumulation of zero is still information we may need to process. If the users wishes to not propagate on an empty/null accumulation result, that should be in the guard.
      you can make a binding to a null field, and it works.
      I see accumulate bindings, akin to bindings on a field. they are not individual facts.
      when you insert into ksessio.insert(object) you insert a whole object, that is without relations at this stage. A field binding is a kind of relation, even if it's null - all fields are relations. What you cannot have is null without it being related to soemthing. For accumulate you have the subject (left input) you have the relation (max/min etc) you have the result - that result is a relation.
      It's about correctness. That an accumulate is empty or null, is still potentially interesting information.
      I think we first need to argue what is the behaviour we want. imho any accumulate binding is a relation, and we allow null relations - as it tells us something about the subject (that the relation is on).
      with regards to compatability, once we have decided on the the beheviour, we can add a kbase conf property to control the behaviour.
      anything that dosnt want null, can add a guard


        Issue Links



              rhn-support-tkobayas Toshiya Kobayashi
              rhn-support-tkobayas Toshiya Kobayashi
              0 Vote for this issue
              3 Start watching this issue