4:43 p.m.
Greetings fellow Droolers,
Each of our rules modifies the fact it matches. We'd like to run each of
those rules exactly once, not reactivating them when a fact changes. I see
from the archives that I'm not the first person to discover that no-loop is
too weak and lock-on-activate too strong for my purposes.
I implemented our requirement with an AgendaListener that remembers hashes
of rules + facts. This works but requires each fact to implement an
interface with a method that returns the hash, and means TWO casts each time
I examine a FactHandle. The whole AgendaFilter is below so you can see what
I mean.
Can anyone suggest a better way? I'm looking more for a better approach
altogether than I am for critique of the implementation of my current
approach, although the latter would not be unwelcome.
private static class Once
implements AgendaFilter {
private final Set<Integer> alreadyActivatedRules = new
HashSet<Integer>();
public boolean accept(Activation activation) {
int hash = activation.getRule().getName().hashCode();
for (FactHandle handle: activation.getFactHandles()) {
Object object = ((DefaultFactHandle) handle).getObject();
hash *= 31;
if (object instanceof Identifiable) {
hash += ((Identifiable) object).getIdentity();
} else if (object instanceof String) {
// We get here when a rule uses from on a string collection
hash += object.hashCode();
} else {
throw new IllegalStateException(
"Don't know what to do with fact class "
+ object.getClass() + ", value " + object);
}
}
boolean accept = !alreadyActivatedRules.contains(hash);
alreadyActivatedRules.add(hash);
return accept;
}
}
Thanks & cheers,
--
| Dave Schweisguth http://schweisguth.org/~dave/ |
| Home: dave at schweisguth.org Work: http://www.nileguide.com/ |
| For compliance with the NJ Right to Know Act: Contents partially unknown |
5:08 p.m.
Could you give some sample rules and the nature of the problem you're solving? Maybe
you don't need to update all of the time with a different approach.
----- Original Message ----
From: Dave Schweisguth <dave(a)schweisguth.org>
To: rules-users(a)lists.jboss.org
Sent: Thu, October 8, 2009 4:43:34 PM
Subject: [rules-users] Better way to run each rule once?
Greetings fellow Droolers,
Each of our rules modifies the fact it matches. We'd like to run each of
those rules exactly once, not reactivating them when a fact changes. I see
from the archives that I'm not the first person to discover that no-loop is
too weak and lock-on-activate too strong for my purposes.
I implemented our requirement with an AgendaListener that remembers hashes
of rules + facts. This works but requires each fact to implement an
interface with a method that returns the hash, and means TWO casts each time
I examine a FactHandle. The whole AgendaFilter is below so you can see what
I mean.
Can anyone suggest a better way? I'm looking more for a better approach
altogether than I am for critique of the implementation of my current
approach, although the latter would not be unwelcome.
private static class Once
implements AgendaFilter {
private final Set<Integer> alreadyActivatedRules = new
HashSet<Integer>();
public boolean accept(Activation activation) {
int hash = activation.getRule().getName().hashCode();
for (FactHandle handle: activation.getFactHandles()) {
Object object = ((DefaultFactHandle) handle).getObject();
hash *= 31;
if (object instanceof Identifiable) {
hash += ((Identifiable) object).getIdentity();
} else if (object instanceof String) {
// We get here when a rule uses from on a string collection
hash += object.hashCode();
} else {
throw new IllegalStateException(
"Don't know what to do with fact class "
+ object.getClass() + ", value " + object);
}
}
boolean accept = !alreadyActivatedRules.contains(hash);
alreadyActivatedRules.add(hash);
return accept;
}
}
Thanks & cheers,
--
| Dave Schweisguth http://schweisguth.org/~dave/ |
| Home: dave at schweisguth.org Work: http://www.nileguide.com/ |
| For compliance with the NJ Right to Know Act: Contents partially unknown |
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:33 a.m.
You could look into using a sequential RETE network
http://blog.athico.com/2007/07/sequential-rete.html
http://www.redhat.com/docs/manuals/jboss/jboss-soa-4.2/html/JBoss_Rules_
Manual/ch02s05s10.html
But as Greg suggests, better understanding your use-case might furnish
other ideas.
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Greg Barton
Sent: 08 October 2009 23:08
To: Rules Users List
Subject: Re: [rules-users] Better way to run each rule once?
Could you give some sample rules and the nature of the problem you're
solving? Maybe you don't need to update all of the time with a
different approach.
----- Original Message ----
From: Dave Schweisguth <dave(a)schweisguth.org>
To: rules-users(a)lists.jboss.org
Sent: Thu, October 8, 2009 4:43:34 PM
Subject: [rules-users] Better way to run each rule once?
Greetings fellow Droolers,
Each of our rules modifies the fact it matches. We'd like to run each of
those rules exactly once, not reactivating them when a fact changes. I
see
from the archives that I'm not the first person to discover that no-loop
is
too weak and lock-on-activate too strong for my purposes.
I implemented our requirement with an AgendaListener that remembers
hashes
of rules + facts. This works but requires each fact to implement an
interface with a method that returns the hash, and means TWO casts each
time
I examine a FactHandle. The whole AgendaFilter is below so you can see
what
I mean.
Can anyone suggest a better way? I'm looking more for a better approach
altogether than I am for critique of the implementation of my current
approach, although the latter would not be unwelcome.
private static class Once
implements AgendaFilter {
private final Set<Integer> alreadyActivatedRules = new
HashSet<Integer>();
public boolean accept(Activation activation) {
int hash = activation.getRule().getName().hashCode();
for (FactHandle handle: activation.getFactHandles()) {
Object object = ((DefaultFactHandle) handle).getObject();
hash *= 31;
if (object instanceof Identifiable) {
hash += ((Identifiable) object).getIdentity();
} else if (object instanceof String) {
// We get here when a rule uses from on a string collection
hash += object.hashCode();
} else {
throw new IllegalStateException(
"Don't know what to do with fact class "
+ object.getClass() + ", value " + object);
}
}
boolean accept = !alreadyActivatedRules.contains(hash);
alreadyActivatedRules.add(hash);
return accept;
}
}
Thanks & cheers,
--
| Dave Schweisguth
http://schweisguth.org/~dave/ |
| Home: dave at schweisguth.org Work:
http://www.nileguide.com/ |
| For compliance with the NJ Right to Know Act: Contents partially
unknown |
_______________________________________________
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
4:46 p.m.
Fellow Droolers,
On Fri, Oct 09, 2009 at 09:33:38AM +0100, Anstis, Michael (M.) wrote:
From: Dave Schweisguth <dave(a)schweisguth.org>
> Each of our rules modifies the fact it matches. We'd like to run each of
> those rules exactly once, not reactivating them when a fact changes.
> [...]
You could look into using a sequential RETE network
http://blog.athico.com/2007/07/sequential-rete.html
http://www.redhat.com/docs/manuals/jboss/jboss-soa-4.2/html/JBoss_Rules_
Manual/ch02s05s10.html
But as Greg suggests, better understanding your use-case might furnish
other ideas.
First, SequentialOption seems to be exactly what I was looking for; many
thanks. I set it and removed my AgendaFilter and my tests all pass, and
faster.
Nonetheless here's the use case for those interested: My principal facts are
objects which I'll call Things which have an ID, a bunch of properties
(unmodifiable fields), and a bunch of named numeric attributes which to keep
things simple I'll treat as a Map<String, Long>. The goal of the rules is to
calculate the attributes.
A typical rule looks like
when thing: Thing(description matches ".*leaves.*")
then modify (thing) { attributes.green = 100 }
Clearly one wants a rule like this to run only once. Since in a given rules
session there are multiple rules like this, no-loop wasn't sufficient; after
one rule fired it would activate another already-run rule on the same Thing,
and then vice versa, forever. With all the rules in the same ruleflow group
lock-on-active was too much in that it allowed only one rule to run. (It
occurs to me now that I might have made each rule no-loop and run it in a
new session; fortunately I don't seem to have to try that now.)
SequentialOption seems to fit this use case perfectly. Of course I'll be
interested if anyone has a still better way to address it.
Side note: Wolfgang, you were wondering why my AgendaFilter needed the
Identifiable interface. You can see from the above that if I wanted to
prevent a rule from firing more than once on the same Thing, I'd need to
recognize the Thing after the rule fired and its attributes (which affect
.equals and .hashCode) changed. It occurs to me now that I could just have
used object identity (==), since rules don't assert new Things. A form of
equals which considered only Thing's ID would also have been more correct
than my hashCode-like solution. Fortunately I no longer need this approach
at all.
Thanks all for your interest and support!
Cheers,
--
| Dave Schweisguth http://schweisguth.org/~dave/ |
| Home: dave at schweisguth.org Work: http://www.nileguide.com/ |
| For compliance with the NJ Right to Know Act: Contents partially unknown |
6:28 p.m.
Greetings:
I have watched this thread with interest as person after person had
another solution. Perhaps mine would be the simplest. If we stop to
think about what IS a rulebase and remember that it is part of the AI
approach and originally intended to solve extremely complex problems
then the answer (OK, the answer to me without sufficient information)
is that this is not a rulebase problem. The whole thing "sounds like"
a procedural problem where values are modified and rules are fired
only once. (Remember - I don't have the whole project requirements
nor what was really needed in front of me.) This is not a rulebase
(think AI, complex) problem at all. That, together with the
revelation that there are no Thing objects asserted on the RHS (and
probably not any objects at all) means that this is not a forward nor
backward chaining problem. It is procedural and should have been
solved with Java, C, C++ or something of that nature.
OK, preaching time is over. Back to work, Serfs!! :-)
One last thing. Considering that the quality of the October Rules
Fest went WAY up (the best, maybe, since the Dartmouth Conference in
1956) and the registrations went down, I get the feeling that geeks
either are not interested in this kind of thing OR that the geeks can
not get the money to go to a conference. The money for going to a
conference seems to go to the Marketing departments and Business
Analysts, not geeks. After all, we (the geeks, techies, IT guys,
whatever the nomenclature is in your particular company) are supposed
to learn this stuff on our own. In my opinion, it can be done that
way with 10 to 15 years devotion to the art and science of AI in
general and RBS in particular. Now, all that being said, maybe you
(the geek) need to take a weeks vacation, spend your own money and
come to ORF 2009. It could jolly well be the last one for a while.
So, like Woodstock, if you missed it, you missed it. There never was
another one of the quality and magnitude. And only those who were
there could talk about what happened and why it was so totally awesome.
SDG
James Owen
Founder October Rules Fest
Senior Consultant / Architect KBSC
http://www.kbsc.com
http://www.OctoberRulesFest.org
Twitter: OctRulesFest
Blogs:
http://JavaRules.blogspot.com [Rulebased Systems Blog]
http://ORF2009.blogspot.com [October Rules Fest Blog]
http://exscg.blogspot.com/ [Expert Systems Consulting Group Blog]
"If I have seen a little further it is by standing on the shoulders of
giants."
Sir Isaac Newton in a letter to Robert Hooke, 5 Feb 1676
Come to October Rules Fest and stand on the shoulders of the Giants of
the industry; if only for a week.
On Oct 9, 2009, at 4:46 PM, Dave Schweisguth wrote:
Fellow Droolers,
On Fri, Oct 09, 2009 at 09:33:38AM +0100, Anstis, Michael (M.) wrote:
> From: Dave Schweisguth <dave(a)schweisguth.org>
>> Each of our rules modifies the fact it matches. We'd like to run
>> each of
>> those rules exactly once, not reactivating them when a fact changes.
>> [...]
>
> You could look into using a sequential RETE network
>
> http://blog.athico.com/2007/07/sequential-rete.html
>
> http://www.redhat.com/docs/manuals/jboss/jboss-soa-4.2/html/JBoss_Rules_
> Manual/ch02s05s10.html
>
> But as Greg suggests, better understanding your use-case might
> furnish
> other ideas.
First, SequentialOption seems to be exactly what I was looking for;
many
thanks. I set it and removed my AgendaFilter and my tests all pass,
and
faster.
Nonetheless here's the use case for those interested: My principal
facts are
objects which I'll call Things which have an ID, a bunch of properties
(unmodifiable fields), and a bunch of named numeric attributes which
to keep
things simple I'll treat as a Map<String, Long>. The goal of the
rules is to
calculate the attributes.
A typical rule looks like
when thing: Thing(description matches ".*leaves.*")
then modify (thing) { attributes.green = 100 }
Clearly one wants a rule like this to run only once. Since in a
given rules
session there are multiple rules like this, no-loop wasn't
sufficient; after
one rule fired it would activate another already-run rule on the
same Thing,
and then vice versa, forever. With all the rules in the same
ruleflow group
lock-on-active was too much in that it allowed only one rule to run.
(It
occurs to me now that I might have made each rule no-loop and run it
in a
new session; fortunately I don't seem to have to try that now.)
SequentialOption seems to fit this use case perfectly. Of course
I'll be
interested if anyone has a still better way to address it.
Side note: Wolfgang, you were wondering why my AgendaFilter needed the
Identifiable interface. You can see from the above that if I wanted to
prevent a rule from firing more than once on the same Thing, I'd
need to
recognize the Thing after the rule fired and its attributes (which
affect
.equals and .hashCode) changed. It occurs to me now that I could
just have
used object identity (==), since rules don't assert new Things. A
form of
equals which considered only Thing's ID would also have been more
correct
than my hashCode-like solution. Fortunately I no longer need this
approach
at all.
Thanks all for your interest and support!
Cheers,
--
| Dave Schweisguth http://schweisguth.org/~dave/
|
| Home: dave at schweisguth.org Work: http://www.nileguide.com/
|
| For compliance with the NJ Right to Know Act: Contents partially
unknown |
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
8:13 p.m.
James,
On Fri, Oct 09, 2009 at 06:28:21PM -0500, James Owen wrote:
[...] The whole thing "sounds like" a procedural problem
where values are
modified and rules are fired only once. [...]
You're right, and I've felt bad about using this very powerful system in
such a limited way. Nonetheless Drools feels like an excellent fit for us:
we do have the requirement of having rules editable by non-engineers, and
Drools provides all of the structure around that that we'd otherwise have
had to come up with, plus a lot of room to grow. I've actually been
wondering whether anyone would suggest a way to solve the problem by
designing the rules and/or facts differently!
I also left out various complications: we have other classes of facts on
the LHS, and Thing's attributes appear on the LHS as well as its
unmodifiable properties. I considered a design where attributes were first-
class facts, but it seemed to run in to the same problem. I don't think any
of that goes against your basic point, however. What I wonder is whether it's
an inappropriate problem for the tool or merely inexpert use of the tool.
Cheers,
--
| Dave Schweisguth http://schweisguth.org/~dave/ |
| Home: dave at schweisguth.org Work: http://www.nileguide.com/ |
| For compliance with the NJ Right to Know Act: Contents partially unknown |
2:01 a.m.
Hey guys.
II think Daves use case is completely valid in that case. This is what is
normally done in Business Rules - not complex AI problems, but extracting
rules from code. Actually the much more common problem I think...
Cheers
Bernd
-----Ursprüngliche Nachricht-----
Von: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] Im Auftrag von Dave
Schweisguth
Gesendet: Samstag, 10. Oktober 2009 03:14
An: Rules Users List
Cc: Rules Dev List
Betreff: Re: [rules-users] Better way to run each rule once?
James,
On Fri, Oct 09, 2009 at 06:28:21PM -0500, James Owen wrote:
[...] The whole thing "sounds like" a procedural problem
where values
are
modified and rules are fired only once. [...]
You're right, and I've felt bad about using this very powerful system in
such a limited way. Nonetheless Drools feels like an excellent fit for us:
we do have the requirement of having rules editable by non-engineers, and
Drools provides all of the structure around that that we'd otherwise have
had to come up with, plus a lot of room to grow. I've actually been
wondering whether anyone would suggest a way to solve the problem by
designing the rules and/or facts differently!
I also left out various complications: we have other classes of facts on
the LHS, and Thing's attributes appear on the LHS as well as its
unmodifiable properties. I considered a design where attributes were
first-
class facts, but it seemed to run in to the same problem. I don't think
any
of that goes against your basic point, however. What I wonder is whether
it's
an inappropriate problem for the tool or merely inexpert use of the tool.
Cheers,
--
| Dave Schweisguth http://schweisguth.org/~dave/
|
| Home: dave at schweisguth.org Work: http://www.nileguide.com/
|
| For compliance with the NJ Right to Know Act: Contents partially unknown
|
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
2:03 a.m.
[Warning: This email may contain heretical thoughts. Read at your
own risk.]
Again, not knowing all of the facts and project requirements, I can
only say that, so far, it sounds like a great problem for Java or C or
C++. I prefer C++ to Java and C but that's a personal thing based on
not needing to have "Java Expert" on my CV in order to get a job. (I
do know Java and started with it way back in 1997 with version 0.9x
but I don't consider myself an expert yet.)
The CLIPS rulebase is still the fastest bare-bones expert system
except for OPSJ and TECH. In addition, we have lots of experienced C+
+ programmers in the world and if we run low on C++ programmers then
the Java programmers can be taught proper coding techniques and
threading procedures not being used today. [See? I told you it was
heresy.] I wonder if Drools could be re-written in C++ ?? Sounds
like a great project to me. :-)
I say things like this, sometimes in jest and sometimes not, so that
we, the techie programmers and developers, would stop and think about
what we're doing and why. Do we really need to have "Rulebase
Programmer" on our CV so badly that we would use it where it is not
needed? I have seen rulebased systems used the wrong way on many
projects and I just had to walk away. But, enough philosophy for one
evening. Think about it and consider your own personal integrity - if
you do you'll probably find yourself out of a job but you'll be
happier while standing in the unemployment line and wondering "WHY??
Why didn't I just keep my big mouth SHUT??". <grin>
SDG
James Owen
Founder October Rules Fest
Senior Consultant / Architect KBSC
http://www.kbsc.com
http://www.OctoberRulesFest.org
Twitter: OctRulesFest
Blogs:
http://JavaRules.blogspot.com [Rulebased Systems Blog]
http://ORF2009.blogspot.com [October Rules Fest Blog]
http://exscg.blogspot.com/ [Expert Systems Consulting Group Blog]
"If I have seen a little further it is by standing on the shoulders of
giants."
Sir Isaac Newton in a letter to Robert Hooke, 5 Feb 1676
Come to October Rules Fest and stand on the shoulders of the Giants of
the industry; if only for a week.
On Oct 9, 2009, at 8:13 PM, Dave Schweisguth wrote:
James,
On Fri, Oct 09, 2009 at 06:28:21PM -0500, James Owen wrote:
> [...] The whole thing "sounds like" a procedural problem where
> values are
> modified and rules are fired only once. [...]
You're right, and I've felt bad about using this very powerful
system in
such a limited way. Nonetheless Drools feels like an excellent fit
for us:
we do have the requirement of having rules editable by non-
engineers, and
Drools provides all of the structure around that that we'd otherwise
have
had to come up with, plus a lot of room to grow. I've actually been
wondering whether anyone would suggest a way to solve the problem by
designing the rules and/or facts differently!
I also left out various complications: we have other classes of
facts on
the LHS, and Thing's attributes appear on the LHS as well as its
unmodifiable properties. I considered a design where attributes were
first-
class facts, but it seemed to run in to the same problem. I don't
think any
of that goes against your basic point, however. What I wonder is
whether it's
an inappropriate problem for the tool or merely inexpert use of the
tool.
Cheers,
--
| Dave Schweisguth http://schweisguth.org/~dave/
|
| Home: dave at schweisguth.org Work: http://www.nileguide.com/
|
| For compliance with the NJ Right to Know Act: Contents partially
unknown |
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
2:10 a.m.
Hey James.
You should think less technical and more in that (I guess you will hate
it) Business-IT-Alignment. Using Excel or DSL to specify business rules,
so extract it from code and make it readable by non technical people.
Thats the goal!
And Drools is a good tool for this job (and it is one of the goals, look
at Guvnor and the BRMS), even if the problem doesnt really need RETE
algorithms and such.
Cheers
Bernd
Von: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] Im Auftrag von James Owen
Gesendet: Samstag, 10. Oktober 2009 09:03
An: Rules Users List
Betreff: Re: [rules-users] Better way to run each rule once?
[Warning: This email may contain heretical thoughts. Read at your own
risk.]
Again, not knowing all of the facts and project requirements, I can only
say that, so far, it sounds like a great problem for Java or C or C++. I
prefer C++ to Java and C but that's a personal thing based on not needing
to have "Java Expert" on my CV in order to get a job. (I do know Java and
started with it way back in 1997 with version 0.9x but I don't consider
myself an expert yet.)
The CLIPS rulebase is still the fastest bare-bones expert system except
for OPSJ and TECH. In addition, we have lots of experienced C++
programmers in the world and if we run low on C++ programmers then the
Java programmers can be taught proper coding techniques and threading
procedures not being used today. [See? I told you it was heresy.] I
wonder if Drools could be re-written in C++ ?? Sounds like a great
project to me. :-)
I say things like this, sometimes in jest and sometimes not, so that we,
the techie programmers and developers, would stop and think about what
we're doing and why. Do we really need to have "Rulebase Programmer" on
our CV so badly that we would use it where it is not needed? I have seen
rulebased systems used the wrong way on many projects and I just had to
walk away. But, enough philosophy for one evening. Think about it and
consider your own personal integrity - if you do you'll probably find
yourself out of a job but you'll be happier while standing in the
unemployment line and wondering "WHY?? Why didn't I just keep my big
mouth SHUT??". <grin>
SDG
James Owen
Founder October Rules Fest
Senior Consultant / Architect KBSC
http://www.kbsc.com
http://www.OctoberRulesFest.org
Twitter: OctRulesFest
Blogs:
http://JavaRules.blogspot.com [Rulebased Systems Blog]
http://ORF2009.blogspot.com [October Rules Fest Blog]
http://exscg.blogspot.com/ [Expert Systems Consulting Group Blog]
"If I have seen a little further it is by standing on the shoulders of
giants."
Sir Isaac Newton in a letter to Robert Hooke, 5 Feb 1676
Come to October Rules Fest and stand on the shoulders of the Giants of the
industry; if only for a week.
On Oct 9, 2009, at 8:13 PM, Dave Schweisguth wrote:
James,
On Fri, Oct 09, 2009 at 06:28:21PM -0500, James Owen wrote:
[...] The whole thing "sounds like" a procedural problem where values are
modified and rules are fired only once. [...]
You're right, and I've felt bad about using this very powerful system in
such a limited way. Nonetheless Drools feels like an excellent fit for us:
we do have the requirement of having rules editable by non-engineers, and
Drools provides all of the structure around that that we'd otherwise have
had to come up with, plus a lot of room to grow. I've actually been
wondering whether anyone would suggest a way to solve the problem by
designing the rules and/or facts differently!
I also left out various complications: we have other classes of facts on
the LHS, and Thing's attributes appear on the LHS as well as its
unmodifiable properties. I considered a design where attributes were
first-
class facts, but it seemed to run in to the same problem. I don't think
any
of that goes against your basic point, however. What I wonder is whether
it's
an inappropriate problem for the tool or merely inexpert use of the tool.
Cheers,
--
| Dave Schweisguth http://schweisguth.org/~dave/
|
| Home: dave at schweisguth.org Work: http://www.nileguide.com/
|
| For compliance with the NJ Right to Know Act: Contents partially unknown
|
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
12:50 a.m.
I see no cogent reason for implementing Identifiable for each fact class.
The hashCode() any object returns should be distinct enough, especially
considering that all the hash codes are munched together, which is
definitely not *guaranteed* to result in different values for *all* rule and
fact set combinations.
But please do as Greg suggested.
BTW, it's sufficient to end with
return alreadyActivatedRules.add(hash);
-W
On Thu, Oct 8, 2009 at 11:43 PM, Dave Schweisguth <dave(a)schweisguth.org>wrote:
Greetings fellow Droolers,
Each of our rules modifies the fact it matches. We'd like to run each of
those rules exactly once, not reactivating them when a fact changes. I see
from the archives that I'm not the first person to discover that no-loop is
too weak and lock-on-activate too strong for my purposes.
I implemented our requirement with an AgendaListener that remembers hashes
of rules + facts. This works but requires each fact to implement an
interface with a method that returns the hash, and means TWO casts each
time
I examine a FactHandle. The whole AgendaFilter is below so you can see what
I mean.
Can anyone suggest a better way? I'm looking more for a better approach
altogether than I am for critique of the implementation of my current
approach, although the latter would not be unwelcome.
private static class Once
implements AgendaFilter {
private final Set<Integer> alreadyActivatedRules = new
HashSet<Integer>();
public boolean accept(Activation activation) {
int hash = activation.getRule().getName().hashCode();
for (FactHandle handle: activation.getFactHandles()) {
Object object = ((DefaultFactHandle) handle).getObject();
hash *= 31;
if (object instanceof Identifiable) {
hash += ((Identifiable) object).getIdentity();
} else if (object instanceof String) {
// We get here when a rule uses from on a string collection
hash += object.hashCode();
} else {
throw new IllegalStateException(
"Don't know what to do with fact class "
+ object.getClass() + ", value " + object);
}
}
boolean accept = !alreadyActivatedRules.contains(hash);
alreadyActivatedRules.add(hash);
return accept;
}
}
Thanks & cheers,
--
| Dave Schweisguth
http://schweisguth.org/~dave/<http://schweisguth.org/%7Edave/>|
| Home: dave at schweisguth.org Work: http://www.nileguide.com/|
| For compliance with the NJ Right to Know Act: Contents partially unknown
|
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5527
days inactive
5529
days old
9 comments
6 participants
participants (6)
-
Anstis, Michael (M.) -
Bernd Rücker -
Dave Schweisguth -
Greg Barton -
James Owen -
Wolfgang Laun