That's probably the best way to go. I think it's a case of experimentation to work
out what runs best (and please report your results). Things to consider are what order you
have the conditions in the rules (the control fact first is probably most efficient but
may be worth comparing with it at the end) and the order you insert facts - do you insert
the control fact first or last.
Thomas
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On
Behalf Of Vincent Legendre
Sent: 21 March 2011 13:47
To: Rules Users List
Subject: Re: [rules-users] Limiting rule evaluation--not firing
ok.
So the only way to do that is to add a control fact, and update it at runtime...
Do you think that using the "control fact" method will speed up the execution
time for a large ruleset that have different ruleflow-group ?
My feeling is yes, especially if "first" rules does many updates, but I
haven't done any tests.
Le 21/03/2011 14:37, Swindells, Thomas a écrit :
The thing to remember is that fact evaluation occurs at object insert/update time, not at
the point you call fireAllRules. Salience, Agenda and rufeflow control on the other hand
are runtime conditions which control which rules are actually activated in what order.
Thomas
From:
rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org>
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Vincent Legendre
Sent: 21 March 2011 13:34
To: Rules Users List
Subject: Re: [rules-users] Limiting rule evaluation--not firing
And what about ruleflow-group ?
There is no network filtering for that too ? The ruleflow-group behaves like an agenda
filter, but still evaluate all nodes ?
Could we imagine setting "tags" to nodes, and stop propagation for node that
does not declare the current task tag ?
Le 21/03/2011 14:20, Edson Tirelli a écrit :
The algorithm as is does eager evaluation, as for the general case that is still better
than doing selective evaluation.
If, in your case, the decision of which rules to fire is an arbitrary application
decision, and not based on the actual constraints of the rules themselves, then the only
way would be by creating a control fact:
rule 1
when
ControlFact( phase == Phase.ONE )
...
rule 2
when
ControlFact( phase == Phase.TWO )
...
This way, if the control fact is the first pattern in each rule it effectively disables
all the beta evaluations for rules of phases other than the current one. Just be aware
that by blocking the eager evaluation this way, phase switches are heavier than without
the control fact, where most constraints were already previously evaluated. Obvious, but
worth saying out loud... :)
There is also a feature that Leonardo is working on that makes the engine automatically
unlink and relink parts of the network, based on the existence and possibility of matching
the other required facts in a rule LHS. It might achieve similar results to what you are
looking for in some cases, but that is totally based on the constraints in there and not
on any arbitrary application decision.
Edson
________________________________
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the
postmaster@nds.com<mailto:postmaster@nds.com> and delete it from your system as well
as any copies. The content of e-mails as well as traffic data may be monitored by NDS for
employment and security purposes. To protect the environment please do not print this
e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users