11:05 p.m.
The basic rule is this: If modify is called on a fact it causes
reevaluation of all LHSs where facts of that type are used.
You may omit modify if the change does not have any effect on the
logic, and you may omit it if this particular change should be hidden
from the engine. (There's the use case of collecting facts A in a
Collection property of fact B with a rule combining a (new) A with a
B: clearly, modify of B would cause the rule to fire over and over
again, which might be prevented using no-loop - but other occurrences
of B might be reevaluated, too.)
A more selective reaction to modification is possible using the
"property reactive" feature - see the docs.
-W
On 15/06/2014, Poissy.B <poissy.b(a)gmail.com> wrote:
Thanks Wolfgang. Actually I kind of figured out how to fix it but am
not
sure why it is fixed.
First to explain the context, this erratic rule belongs to a rule
flow-group B that is executed right after another group (A).
There is actually a rule in A that modifies $mainProcess, more
specifically, it adds the actual ItemAwareElements that should be returned
by the methods getGivenResources and getReceivedResources. However I did
not enclose that in a "modify" statement. My point was that it is useless
to let the WM know as that modification has no influence on group A rules.
And I was thinking that it does not even matter for group B rules as I am
playing with fact's internal properties and not the fact per se.
(specifically: a HashSet having Set values).
I guess I was wrong assuming all this. So my question is:
- Do we need to use the modify statement whenever the state of an object
from the working memory is changed? (even if the part of the state that
changed is not relevant to the reasoner)
- In other words, can we sometimes avoid the modify when manipulating facts
to prevent the rules from being re-evaluated uselessly?
Thanks!
On Sun, Jun 15, 2014 at 3:59 PM, Wolfgang Laun <wolfgang.laun(a)gmail.com>
wrote:
> OK, it's a bug all right. 5.4.0 had some problems. It might be worth
> trying a later 5.x version.
> -W
>
> On 15/06/2014, Poissy.B <poissy.b(a)gmail.com> wrote:
> > Yes it does fire if I comment either of them, and I get the exact same
> > response.
> >
> > I am using Drools 5.4.0.Final runtime.
> >
> > Actually Products is the name property of an object of type
> > DataObjectReference (wich implements ItemAwareElementAdapter). The
> > point
> of
> > providing the output was just to show you that the
> > List<ItemAwareElementAdapter> returned by both getGivenResources() and
> > getReceivedResources() is indeed not empty so the "exists" constraint
> > should have been matched.
> >
> > Thanks!
> >
> >
> > On Sun, Jun 15, 2014 at 2:06 PM, Wolfgang Laun
> > <wolfgang.laun(a)gmail.com>
> > wrote:
> >
> >> See inline.
> >>
> >> On 15/06/2014, Poissy.B <poissy.b(a)gmail.com> wrote:
> >> > Hello,
> >> >
> >> > I am a little bit confused as I don't get what I am doing wrong.
> >> > Here
> >> > is
> >> my
> >> > rule:
> >> >
> >> > **************************
> >> > rule "Exchange Pattern"
> >> > when
> >> > $p2: ProcessAdapter()
> >> > $mainProcess: ProcessAdapter( isMainProcess(), this!=$p2)
> >> > MessageFlowAdapter ( fromProcess == $mainProcess,
> >> > toProcess==$p2)
> >> > MessageFlowAdapter ( fromProcess == $p2,
> >> > toProcess==$mainProcess)
> >> > exists ItemAwareElementAdapter( ) from
> >> > $mainProcess.getReceivedResources($p2)
> >> > exists ItemAwareElementAdapter( ) from
> >> > $mainProcess.getGivenResources($p2)
> >> > then
> >> > System.out.println("** FOUND EXCHANGE PATTERN betwwen
> >> > "+$mainProcess.getParticipant().getName()+" AND
> >> > "+$p2.getParticipant().getName());
> >> > System.out.println("Given:
> >> >
> >>
>
"+$mainProcess.getGivenResources($p2)+$mainProcess.getGivenResources($p2).size());
> >> > System.out.println("Received:
> >> >
> >>
>
"+$mainProcess.getReceivedResources($p2)+$mainProcess.getReceivedResources($p2).size());
> >> > System.out.println("Intersection:
> >> >
> >>
>
"+$mainProcess.intersectGivenAndReceivedResourcesWithProcess($p2)+$mainProcess.intersectGivenAndReceivedResourcesWithProcess($p2).size());
> >> > end
> >> > **************************
> >> >
> >> > This rule is never fired, although I know it should.
> >> >
> >> > When I comment out the ONE OF the two "exists" constraints, I
get
> >> > this
> >> > output:
> >>
> >> Does the rule fire when you comment out either "exists"
conditional
> >> element,
> >> i.e., it doesn't matter which one is removed?
> >>
> >> Which Drools version are you using?
> >>
> >> -W
> >>
> >> >
> >> > **************************
> >> > ** FOUND EXCHANGE PATTERN betwwen Amazon AND Ship.Comp.
> >> > Given: [Products (ID:DataObjectReference_2)]1
> >> > Received: [Products (ID:DataObjectRefeference_GEN7)]1
> >> > Intersection: [Products (ID:DataObject_2)]1
> >> > **************************
> >>
> >> I can't say that a display of fact type "Products" is clearly
> >> indicating
> >> the
> >> presence of an ItemAwareElementAdapter. That said, the rule shouldn't
> >> fire even with a single "exists", so I assume this is an
interface
> >> implemented
> >> by Products.
> >>
> >> >
> >> > >From the output you can see that the rule should have been fired
> >> > with
> >> the
> >> > two "exists" constrains as both conditions are met, but it
doesn't.
> >> > I am kind of new to Drools so I may be doing an horrible mistake but
> >> google
> >> > haven't been my friend so far. Any help will be very appreciated!
> >> >
> >> > Thanks.
> >> > Anis
> >> >
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>