The intent was to define a common set of filtering conditions for each combination of
event type and entry point, implemented by the super rule.
--- On Tue, 11/24/09, Edson Tirelli <ed.tirelli(a)gmail.com> wrote:
From: Edson Tirelli <ed.tirelli(a)gmail.com>
Subject: Re: [rules-users] Does Session effeciently filter unused facts, or...
To: "Rules Users List" <rules-users(a)lists.jboss.org>
Date: Tuesday, November 24, 2009, 6:00 PM
Greg, I believe I fixed this bug in trunk a few weeks
ago. Although I confess I did not understood the intent of
your rules... :)
Barry, you can certainly go either way. Rete is very
efficient on filtering fact types, but of course there is
some overhead on fact handle creation. If performance is
acceptable for you by just inserting events and letting the
engine discard them automatically when not used, I would not
worry about. If you are having performance problems due to
the volumes of non-interesting events and you want to try
pre-filtering, I can give you some pointers on how to find
the fact types used by your rules/queries. In this case, we
might even make a feature of that and have the
"pre-filter" being executed by the engine... ;)
Edson
2009/11/24 Greg Barton <greg_barton(a)yahoo.com>
Well, I was about to say "you could do this using rule
inheritance" but there is a caveat, and possibly a bug.
It almost works. :)
Try this:
rule "BaseStream1Criteria"
enabled false
when
m : Message( foo == "BAR"
) from entry-point "Stream1"
then
System.out.println(
"BaseStream1Criteria" );
end
rule "SubRule1" extends
"BaseStream1Criteria"
when
Message( status == Message.HELLO )
from m;
then
System.out.println( "SubRule1
" );
end
rule "BaseStream2Criteria"
enabled false
when
m : Message( foo == "BAS"
) from entry-point "Stream2"
then
System.out.println(
"BaseStream2Criteria" );
end
rule "SubRule2" extends
"BaseStream2Criteria"
when
Message( status == Message.HELLO )
from m;
then
System.out.println( "SubRule2
" );
end
Basically, define one rule for each entry point that has
the global criteria for that entry point. Then extend that
rule.
The caveat is that it seems you can't use the events
matched in the super-rule in the RHS of the subrule. (Try
putting the object "m" matched into the action of
either of the subrules. It neither validates in eclipse
nor compiles at runtime, drools 5.0.1.) If this isn't
fixed in trunk (I can't check at the moment) I'll
open a jira.
Code attached. When you run it, this should be the
output:
SubRule2
SubRule1
--- On Mon, 11/23/09, Barry Kaplan <groups1(a)memelet.com>
wrote:
> From: Barry Kaplan <groups1(a)memelet.com>
> Subject: [rules-users] Does Session effeciently
filter unused facts, or...
> To: rules-users(a)lists.jboss.org
> Date: Monday, November 23, 2009, 9:12 PM
>
> ... should I put a filter before insert().
>
> I will have lots of events coming from hardware
devices,
> only some of which
> be applicable to a given session instance. I've
tried
> extracting the
> declared types from the packages, but that doesn't
include
> classes used in
> patterns which where only imported. So determine the
actual
> set of event
> classes used by a given set of packages seems not to
be so
> easy.
>
> I've drilled down to
EntryPointNode.assertObject......
> --
> View this message in context:
http://old.nabble.com/Does-Session-effeciently-filter-unused-facts%2C-or....
> Sent from the drools - user mailing list archive at
>
Nabble.com.
>
> _______________________________________________
> 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
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com
-----Inline Attachment Follows-----
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users