[jboss-jira] [JBoss JIRA] (DROOLS-365) Rule attribute for adding inverse of consequence as rule condition

[Adar Dembo (JIRA)]

    [ https://issues.jboss.org/browse/DROOLS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929282#comment-12929282 ] 

Adar Dembo commented on DROOLS-365:
-----------------------------------

I don't see the problem with modifications to multiple facts: you could condition on the NOT of the logical AND of all facts. Or the logical OR; I think both approaches are defensible. As for your second example, what's the issue with multiple rules asserting the same fact?

In any case, I think the biggest challenge to implementation is that the rule consequence is a snippet of Java, and thus can do absolutely anything. For example, it could conditionally assert a fact. How do you modify the rule then? Also conditionally? Based on runtime input? It seems really challenging.

The example that actually drove me to file this bug looks something like this:

{noformat}
rule "1"
  when
    accumulate (Foo($type : type, $value : value), $total : sum($value))
  then
    insert(new Bar($type, $total));
end

rule "handle all Bars of type first"
  when
    $bar : Bar(type == 'first', $total : total)
    ...
  then
    retract($bar);
end

rule "handle all Bars of type second"
  when
    $bar : Bar(type == 'second', $total : total)
    ...
  then
    retract($bar);
end

rule "generic rule to handle all leftover Bars"
salience -1 // let custom Bar rules fire first
  when
    $bar : Bar($total : total)
    ...
  then
    retract($bar);
end
{noformat}

The flow here is to convert the sum of all Foos (of a given type) into a Bar. Subsequently, there's a rule to handle each type of Bar, with a generic rule to handle Bars without a custom rule. To get that fallthrough behavior I need:
# Salience -1 on the generic rule, so it fires last.
# Retraction of each Bar as it's processed.

However, the retraction causes the summation rule to reactivate, unless I add an explicit {{not Bar(type == $type)}} condition to the rule. Granted, in this case, I suppose the feature request mentioned here wouldn't work, because it'd add {{not Bar(type == $type, total == $total)}}, which would allow the rule to reactivate.

For this example, I don't think equality-based assertion will solve my problem; fundamentally the retraction of a Bar causes us to reevaluate the accumulate rule. Likewise, I don't think @propertyReactive will help either; the issue here isn't with modifying a single property, but with removing an entire fact.
                
> Rule attribute for adding inverse of consequence as rule condition
> ------------------------------------------------------------------
>
>                 Key: DROOLS-365
>                 URL: https://issues.jboss.org/browse/DROOLS-365
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Adar Dembo
>            Assignee: Mark Proctor
>
> I have quite a few rules that look like this:
> {noformat}
> rule "if foo then bar"
>   when
>     Foo($a : a, $b : b)
>     not Bar(a == $a, b == $b)
>   then
>     insert(new Bar($a, $b));
> end
> {noformat}
> This is a fairly common pattern for me: a rule should not activate if the facts generated by its consequence were already asserted. It's a pattern I use extensively to generate linear (i.e. non-repeating) workflows.
> Ideally I'd be able to express it as follows:
> {noformat}
> rule "if foo then bar"
> condition-on-inverse-of-consequence
>   when
>     Foo($a : a, $b : b)
>   then
>     insert(new Bar($a, $b));
> end
> {noformat}
> And {{condition-on-inverse-of-consequence}} would cause Drools to generate the right kind of condition, which would be the inverse of the fact changes made by the consequence.
> I think {{lock-on-active}} is similar but harsher: it prevents the rule from firing a second time altogether, regardless of input. At least, that's based on my reading of the docs. In my example, that would be equivalent to  {{not Bar()}} condition in the rule, which is stricter than {{not Bar(a == $a, b == $b)}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira