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

executable model doesn't resolve bind variable from another pattern of the same type in method call in LHS for property reactivity

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 8.40.0.Final
    • 7.67.0.Final, 7.73.0.Final, 8.36.0.Final
    • executable model
    • None
    • 2023 Week 15-17 (from Apr 10), 2023 Week 18-20 (from May 1), 2023 Week 21-23 (from May 22), 2023 Week 24-26 (from Jun 12)
    • 4
    • NEW
    • NEW
    • ---
    • ---

    Description

      Issue Description:

      DROOLS-7372 fixed for a bind variable in the same pattern, but a bind variable from another pattern causes the same reactivity issue.

      example 1

      rule "Rule 1"
          when
              $fact1 : Fact1( $id1 : id == 1 )
              Fact2( $id2 : id == 2 ) 
              Fact2( id == 2, convertToIdString($id2) == "id2" )  
          then
              System.out.println("***** Action of " + drools.getRule().getName());
              modify($fact1) {
                  value = $id2
              }
      end
      
      rule "Rule 2"
          when
              Fact1( $id1 : id == 1, value == 2 )
              $fact2 : Fact2( $id2 : id == 2 )
          then
              System.out.println("***** Action of " + drools.getRule().getName());
      
              modify($fact2) {
                  value = $id1
              }
      end
      

      Currently:
      non-exec-model : property reactive. Not loop
      exec-model : class reactive. Infinite loop

      => This is an ambiguous case. $id2 is a bind viable from the previous pattern, so should not trigger property reactive (= exec-model is correct). However, both are the same type so eventually, Fact2.id is the target of property reactive. We would want to meet the exec-model behaviour (plus, compile time warning), but not rushing... we may document the behaviour difference at the moment.

      Acceptance Criteria:

      • Fix non-exec-model to be class reactive to meet the exec-model behavior.
      • Raise a compile time WARN for both non-exec-model and exec-model

      Attachments

        Issue Links

          Activity

            People

              rhn-support-tkobayas Toshiya Kobayashi
              rhn-support-tkobayas Toshiya Kobayashi
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: