Modify not causing rules to refire

[Jeff Schneller]

I am using xls decision table and the following is what is produced as the source of the rules.  The MOTORS_27 rule is not firing after the MOTORS_36 rule fires.  My understanding is a re-fire should occur.  However, if I reverse the order of the rules then MOTORS_36 fires and then MOTORS_27 fires which makes sense since it is after the modify.   Why when MOTORS_27 is before MOTORS_36 is it not being re-fired?

rule "MOTORS_27"
    when
        prod : Product(sku != "1")
        $txt1 : TextOption(sku == "motor_model")
        eval($txt1.getValue() == "CM")
    then
        prod.setOptionEnabled( "bc", false, "Not available" );
end

rule "MOTORS_36"
    no-loop true
    when
        prod : Product(sku != "1")
        $opt1 : TextChoiceOption(sku == "motor_type")
        exists (OptionValue(optionValueValue in ("P")) from $opt1.value)
        $dimension: DimensionOption(sku == "dim", widthValue > "30.0", widthValue <= "36.0", heightValue <= "36.0")
        $txt1 : TextOption(sku == "motor_model")
    then
        modify ($txt1) { setValue("CM")}
end

[Jeff Schneller]

As a follow-up if I remove the no-loop true in rule 36 then rule 27 will fire after rule 36 is fired.  

My understanding was no-loop prevented the rule which has the no-loop defined from being fired again because of the THEN clause of the same rule.  

Is my understanding wrong or is something else going on?

[Matteo Mortari]

Hi Jeff,

I believe in rule 27, you can do without having to use "eval()" which is discouraged.

That is because you can "merge" the constraint inside the previous pattern, and iirc eval is not reactive to the property which is being modified in the RHS of the other rule.

Then, separately, removing the no-loop makes rule 36 re-entrant as there is nothing to "guard" the rule should not be fired again since TextOption.Value = "CM" is/was already set (eg a constraint guarding TextOption's value is different than "CM").

Hope this helps!

MM

--
Matteo Mortari
linkedin.com/in/matteomortari
youtube.com/@MatteoMortari

--
You received this message because you are subscribed to the Google Groups "Drools Usage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/b67b35a4-9b93-4f97-91e6-6d2bec48f1c6n%40googlegroups.com.

[Jeff Schneller]

I have already changed rule 27 to remove the eval.

As for rule 36 being re-entrant - I removed the no-loop and it did not fire again without any "guard" being present.  Based on what you stated it should be refiring because of the RHS however that is not the case.

Is my understanding of no-loop correct?  If so, why would rule 27 not refire if rule 36 is set to no-loop?

[Matteo Mortari]

Hi Jeff,

On Fri, 13 Jan 2023, 21:57 Jeff Schneller, <jeff.sc...@gmail.com> wrote:

I have already changed rule 27 to remove the eval.

 Great!

As for rule 36 being re-entrant - I removed the no-loop and it did not fire again without any "guard" being present.  Based on what you stated it should be refiring because of the RHS however that is not the case.

Not really, that was more of a general advice I tend to implement. 

In that case, since you are modifying a property on a pattern, it correctly does not re entry again since 36 doesn't have to be reactive on the field. Apologies if I may have confused you.

Is my understanding of no-loop correct?  If so, why would rule 27 not refire if rule 36 is set to no-loop?

No-loop avoid for the same previously met conditions

https://docs.drools.org/8.32.0.Final/drools-docs/docs-website/drools/language-reference/index.html#ref-rules-attributes_drl-rules

Say you (globally) updated any of the pattern (I'm not suggesting you do so) resulting in the same conditions.

If anything else is missing, it would be ideal to provide a small reproducer, so that any further doubts can be clarified by fixing the actual data and version.

Hope this helps!

MM

To view this discussion on the web visit https://groups.google.com/d/msgid/drools-usage/c9ba277f-6197-448f-9f12-93ae7ae896aan%40googlegroups.com.

[Jeff Schneller]

On Friday, January 13, 2023 at 5:25:22 PM UTC-5 matteo wrote:

Hi Jeff,

On Fri, 13 Jan 2023, 21:57 Jeff wrote:

I have already changed rule 27 to remove the eval.

 Great!

As for rule 36 being re-entrant - I removed the no-loop and it did not fire again without any "guard" being present.  Based on what you stated it should be refiring because of the RHS however that is not the case.

Not really, that was more of a general advice I tend to implement. 

In that case, since you are modifying a property on a pattern, it correctly does not re entry again since 36 doesn't have to be reactive on the field. Apologies if I may have confused you.

So because the LHS doesn't look at the property that I am setting in the RHS  it won't be re-activated?   If the LHS referenced TextOption(sku== "motor_model", value != null) then it would be re-activated?

 

Is my understanding of no-loop correct?  If so, why would rule 27 not refire if rule 36 is set to no-loop?

No-loop avoid for the same previously met conditions

https://docs.drools.org/8.32.0.Final/drools-docs/docs-website/drools/language-reference/index.html#ref-rules-attributes_drl-rules

According to the docs by using no-loop it won't reactivate the same rule that just fired it's RHS.  It doesn't explain why rule 27 is not firing.

 

Say you (globally) updated any of the pattern (I'm not suggesting you do so) resulting in the same conditions.

If anything else is missing, it would be ideal to provide a small reproducer, so that any further doubts can be clarified by fixing the actual data and version.

What would I need to provide for a reproducer?  There are other rules but those are firing correctly.  I just listed the 2 rules that are causing problems.

 

Hope this helps!

MM

On Friday, January 13, 2023 at 3:08:20 PM UTC-5 matteo wrote:

Hi Jeff,

I believe in rule 27, you can do without having to use "eval()" which is discouraged.

That is because you can "merge" the constraint inside the previous pattern, and iirc eval is not reactive to the property which is being modified in the RHS of the other rule.

Then, separately, removing the no-loop makes rule 36 re-entrant as there is nothing to "guard" the rule should not be fired again since TextOption.Value = "CM" is/was already set (eg a constraint guarding TextOption's value is different than "CM").

Hope this helps!

MM

--
Matteo Mortari
linkedin.com/in/matteomortari
youtube.com/@MatteoMortari

[Jeff Schneller]

This is continuing to be a problem for me.

I call a setValue on a fact and then call update on the fact.  I also tried a modify but that didn't work either.

when

   condition is true

then

   fact.setValue("myvalue");

   update(fact);

However other rules that have fact in them are not being re-run.  

when

    fact(value == "myvalue")

then

    do something 

Another similar rule that is not rerun is this.  I know that otherfact's value equals "some value" because I see it in my application.

when

    fact(value == "myvalue")

    otherfact(value == "some value")

then

    do something

Can anyone explain why update isn't causing rules to re-fire?    I am seriously questioning if 7.73.0.Final has an issue.