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

BigDecimal different compare behavior depending on the amount of conditions

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • 7.74.0.Final
    • 7.51.0.Final
    • None
    • None
    • Undefined
    • NEW
    • NEW

      We stumbled over an interesting behavior. Depending on the amount of checks with the same field the comparison behavior for BigDecimal values changes.

       In this example we have an object with a BigDecimal as value:

      import java.math.BigDecimal;

declare TestObject
  value: BigDecimal
end

rule "Add number 1"
 when
 then
  insertLogical( new TestObject( new BigDecimal( "1.0" ) ) );
  insertLogical( new TestObject( new BigDecimal( "2.0" ) ) );
  insertLogical( new TestObject( new BigDecimal( "3.0" ) ) );
end

      Following two rules fire:

      rule "Check BigDecimal 1"
  when
    TestObject( value == 1B )
  then
    System.out.println( "_______________________BLUB 1" );
end

rule "Check BigDecimal 2"
  when
    TestObject( value == 2B )
  then
    System.out.println( "_______________________BLUB 2" );
end

      When adding another rule like these none of the above fire anymore:

      rule "Check BigDecimal 3"
  when
    TestObject( value == 3B )
  then
    System.out.println( "_______________________BLUB 3" );
end

      This would then only work again rewriting the rules as follows using the exact same value and scale as used when inserting the facts:

      rule "Check BigDecimal 1"
  when
    TestObject( value == 1.0B )
  then
    System.out.println( "_______________________BLUB 1" );
end

rule "Check BigDecimal 2"
  when
    TestObject( value == 2.0B )
  then
    System.out.println( "_______________________BLUB 2" );
end

rule "Check BigDecimal 3"
  when
    TestObject( value == 3.0B )
  then
    System.out.println( "_______________________BLUB 3" );
end

      It seems that the comparison changes (BigDecimal equals(...) vs compareTo(...)) when the amount of checks is >= 3.

      When debugging we stumbled across alphaNodeHashingThreshold which seems to lead into a different path. When this is less than 3 then the MVELConditionEvaluator seems to be used. When 3 or above then it never uses the MVELConditionEvaluator. Not sure if this is related.

       

            rhn-support-tkobayas Toshiya Kobayashi
            d.saruji Danial Saruji (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: