From: Edson Tirelli <tirelli@post.com>
Subject: Re: [rules-users] Chart notation, update, and infinite loops
To: greg_barton@yahoo.com, "Rules Users List" <rules-users@lists.jboss.org>
Date: Tuesday, November 4, 2008, 7:54 PM
That is an excellent project, but it is deep in the core
engine. Great
opportunity to learn all about ReteOO and drools internals,
but will require
some research from your side... we know the general
solution, but you may
still find some obstacles that need to be removed as you
go.
If you are willing to take the challenge, lets move the
discussion to
drools-dev and we can guide you.
[]s
Edson
2008/11/4 Greg Barton <greg_barton@yahoo.com>
I thought drools had this. If you point me in the
right direction (and you
have the time) I'd be happy to work on that.
--- On Tue, 11/4/08, Edson Tirelli
<tirelli@post.com> wrote:
From: Edson Tirelli <tirelli@post.com>
Subject: Re: [rules-users] Chart notation,
update, and infinite loops
To: "Rules Users List"
<rules-users@lists.jboss.org>
Date: Tuesday, November 4, 2008, 7:06 PM
Dan,
This is a feature that is in our to-do list.
Jess calls
it "slot specific
updates". We did not had the time yet to
implement it
though. :(
[]s
Edson
2008/11/4 Dan Seaver <dan.seaver@ge.com>
Your understanding is very close to what
I'm
looking for. I don't mind
having
multiple rule activations in other areas of
the
ruleset when the Fact is
updated, I just don't want the current
rule, the
one with the update
statement, to be reactivated.
Accumulate plus no-loop works fine for the
specific
case of updating
amounts, but I'd like to have something
generic
for more sophisticated
logic
that would be implemented in the
"then"
clause.
Maybe if there was something that looked
specifically
at each property of
the update? In this case, the
"when" clause
is looking at the "name"
property and the "then" clause is
updating
the "amount" property. As the
"name" is not being changed, then
the update
wouldn't reactivate the rule.
Greg Barton wrote:
If you have the control fact that
handles the
"applied == false"
condition
you wouldn't need to prevent
reactivation of
the rule. It would be
handled by the condition.
I'm thinking Edson's accumulate
suggestion would be best, at this point.
If I understand correctly, what you
want is this:
1) One rule Fact/Charge activation per
Charge
instance, with no
reactivation when the Fact is updated.
2) Other Fact dependent rule
activations when the
Fact is updated.
The problem with making (1) happen is
that
you'd still have the matched
Fact being updated once per Charge,
which could
lead to reactivation of
the rules in (2) multiple times, which
you may
not want. If you use
accumulate in the Fact/Charge rule,
plus no-loop
to prevent reactivation,
you get the best of both worlds: single
activation of the Fact/Charge
rule, with a single update to notify
other rules
that the Fact has
changed.
I think what you're after is some
kind of
"modify group," where multiple
calls to modify are counted as just
one, and
rules are notified when the
group is closed out. I'm not sure
how that
would be implemented, because
how do you know when the modifications
are
finished? A low priority
rule,
possibly? Anyway, it doesn't exist
in
drools, afaik.
You could do that kind of thing with an
additional rule that tests for
the
nonexistence of an unprocessed Charge,
then does
the update. Adding in
the control fact for tracking Charges:
rule "Update Amount"
when
amountFact : Fact(name ==
"Amount")
$charge : Charge()
chargeTracker :
ChargeTracker(charge ==
$charge, applied == false)
then
Double amount =
amountFact.getAmount();
Double chargeAmount =
charge.getAmount();
amountFact.setAmount(amount +
chargeAmount);
chargeTracker.setApplied(true);
update(charge);
end
rule "Close Facts After Charges
Applied"
no-loop false
when
amountFact : Fact(name ==
"Amount")
not ChargeTracker(applied ==
false)
then
update(amountFact);
end
You'd probablt also have to prevent
the
"Close Facts" rule from firing
when there's just no ChargeTrackers
in
working memory, too.
Give that a try.
--- On Tue, 11/4/08, Dan Seaver
<dan.seaver@ge.com> wrote:
From: Dan Seaver
<dan.seaver@ge.com>
Subject: Re: [rules-users] Chart
notation,
update, and infinite loops
To: rules-users@lists.jboss.org
Date: Tuesday, November 4, 2008,
1:55 PM
Greg,
1) Yes, in this case I'm
looking for the
cartesian
join.
2) No, I can't add a property
to Charge
as it's
part of our corp Object
Model.
However, I could create a third
object that
manages whether
the Charge has
been processed which works just
fine. Unless
there is a
simpler strategy /
technique, I'll go with that.
Do you know of any way to keep the
rule from
being put back
on the agenda
when amountFact is updated? I want
other
rules to know that
it's been
updated, just not the rule that
made the
change.
Dan
Greg Barton wrote:
1) Do you want to apply all
Charges in
working memory
to all "Amount"
Facts? I ask because the rule
is a
cartesian join
(i.e. no relation
between matched objects) and
that
sometimes performs
in ways users don't
expect. (i.e. all combinations
of
objects that match
the conditions are
affected by the rule)
2) Can you add a property to
the Charge
object? Then
you could use a
boolean named
"applied" to
prevent future
matches.
Rule "Update Amount"
when
amountFact : Fact(name
==
"Amount")
charge : Charge(applied
== false)
then
Double amount =
amountFact.getAmount();
Double chargeAmount =
charge.getAmount();
amountFact.setAmount(amount +
chargeAmount);
update(amountFact);
charge.setApplied(true);
update(charge);
end
If a charge could be applied
to multiple
Facts you
could maintain an
"appliedTo" list of
Facts in
the Charge, and
check that instead of a
simple boolean.
--- On Tue, 11/4/08, Dan
Seaver
<dan.seaver@ge.com> wrote:
From: Dan Seaver
<dan.seaver@ge.com>
Subject: [rules-users]
Chart
notation, update, and
infinite loops
To:
rules-users@lists.jboss.org
Date: Tuesday, November 4,
2008,
11:50 AM
I'm trying to find a
good
technique for
updating
specific facts in working
memory. What I'm
currently doing
is something
like
this:
Rule "Update
Amount"
when
amountFact :
Fact(name ==
"Amount")
charge : Charge()
then
Double amount =
amountFact.getAmount();
Double chargeAmount
=
charge.getAmount();
amountFact.setAmount(amount +
chargeAmount);
update(amountFact);
end
The update statement
causes an
infinite loop.
I tried using no-loop,
which works
if there is 1
charge,
but not if there
are more than one.
Any help with solutions or
strategies would be
much
appreciated.
--
View this message in
context:
http://www.nabble.com/Chart-notation%2C-update%2C-and-infinite-loops-tp20327483p20327483.html
Sent from the drools -
user mailing
list archive
at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
View this message in context:
http://www.nabble.com/Chart-notation%2C-update%2C-and-infinite-loops-tp20327483p20329780.html
Sent from the drools - user mailing
list
archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
View this message in context:
http://www.nabble.com/Chart-notation%2C-update%2C-and-infinite-loops-tp20327483p20334594.html
Sent from the drools - user mailing list
archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com