Greg Barton wrote:
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.
  
It's non-trivial, especially when evals are involved, but you are welcome to have a go. Not even sure where to begin on this....
I imagine the first thing is that the PropagationContext will need a binary mask, supplied by the modify keyword, which shows the fields modified as part of the modify action. We will then need to do bitmap masking to determine whether a propagation should continue down a route or not. This may be an easier one to do on irc, if you can get there. Just be aware that this is many days, if not weeks work, to get it right with adequate unit testing.

Mark
--- 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