12:32 p.m.
[
https://issues.jboss.org/browse/DROOLS-365?page=com.atlassian.jira.plugin...
]
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
3990
days inactive
3990
days old
0 comments
1 participants
participants (1)
-
Adar Dembo (JIRA)