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] *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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users