11:40 a.m.
I'm learning how to use Drools, but eval presents a problem to me when I am composing
rules. I've read the manual and have a basic understanding of what it is for (very
useful in certain situations!), but is there a better explanation of when it cannot be
avoided?
For example when writing the LHS portion of a rule, I've run into a problem where
literal restrictions alone are fine for one object but inadequate for another. Like so:
$a : X(temp < 100)
$b : Y(running == true)
In both cases class X and class Y have standard Java bean set up for these fields with
appropriate getters and setters, and the corresponding inserted facts see these fields
being updated from time to time. But whereas the first fact causes rule activation when
the temp field meets the rule critiera, the second will never work unless it is re-written
as:
$b : Y()
eval ($b.isRunning() == true)
I've encountered a similar problem with in-line evals where Drools will accept an LHS
like this:
// attempting to find all applicants named Bob
$p : Person(firstName == "Bob")
$ap : Applicant(person == $p)
but it will never cause activation unless you re-write it like this:
$p : Person(firstName == "Bob")
$ap : Applicant( eval(person == $p) )
despite the fact that the Applicant object's person field once set never changes.
So is there a more definitive explanation as to why one is forced to use eval when you
would think that simple literal restrictions would be enough? I've read in other
posts that "eval is evil" and to best avoid it unless necessary, but this is
perplexing me because I haven't yet discovered the way to think about rule composition
that prevents eval use from appearing to be arbitrary. Mostly it's been write what I
think *should* work and if it does then great, it if doesn't then keep adding evals
until it does. For the record, I'm using the java dialect if that makes a difference.
Thanks!
-Allen
4:53 p.m.
Allen,
Both your examples must work just fine:
$b : Y(running == true)
// attempting to find all applicants named Bob
$p : Person(firstName == "Bob")
$ap : Applicant(person == $p)
I can't think about a reason for them to not work. If they aren't, can
you please provide a self contained test case for us to evaluate?
Answering your question, in Drools 4, assuming your facts are beans,
there should be almost no reason for you to fall back into an eval. The
usage of eval is usually related to the need for calculation inside a
constraint or the call of functions.
[]s
Edson
2008/4/24 Bagwell, Allen F <afbagwe(a)sandia.gov>:
I'm learning how to use Drools, but eval presents a problem to me
when I am
composing rules. I've read the manual and have a basic understanding of what
it is for (very useful in certain situations!), but is there a better
explanation of when it cannot be avoided?
For example when writing the LHS portion of a rule, I've run into a problem
where literal restrictions alone are fine for one object but inadequate for
another. Like so:
$a : X(temp < 100)
$b : Y(running == true)
In both cases class X and class Y have standard Java bean set up for these
fields with appropriate getters and setters, and the corresponding inserted
facts see these fields being updated from time to time. But whereas the
first fact causes rule activation when the temp field meets the rule
critiera, the second will never work unless it is re-written as:
$b : Y()
eval ($b.isRunning() == true)
I've encountered a similar problem with in-line evals where Drools will
accept an LHS like this:
// attempting to find all applicants named Bob
$p : Person(firstName == "Bob")
$ap : Applicant(person == $p)
but it will never cause activation unless you re-write it like this:
$p : Person(firstName == "Bob")
$ap : Applicant( eval(person == $p) )
despite the fact that the Applicant object's person field once set never
changes.
So is there a more definitive explanation as to why one is forced to use
eval when you would think that simple literal restrictions would be enough?
I've read in other posts that "eval is evil" and to best avoid it unless
necessary, but this is perplexing me because I haven't yet discovered the
way to think about rule composition that prevents eval use from appearing to
be arbitrary. Mostly it's been write what I think *should* work and if it
does then great, it if doesn't then keep adding evals until it does. For the
record, I'm using the java dialect if that makes a difference.
Thanks!
-Allen
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
11:22 a.m.
I've attached three files containing my test case. I hope they come across.
I've only given an example of the most basic case I mentioned. In the rule file,
I'm only seeing the rule with an eval activate. Both rules should activate when each
object times out.
Thanks for having a look.
-A
________________________________
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On
Behalf Of Edson Tirelli
Sent: Thursday, April 24, 2008 3:54 PM
To: Rules Users List
Subject: Re: [rules-users] When is eval unavoidable?
Allen,
Both your examples must work just fine:
$b : Y(running == true)
// attempting to find all applicants named Bob
$p : Person(firstName == "Bob")
$ap : Applicant(person == $p)
I can't think about a reason for them to not work. If they aren't, can you
please provide a self contained test case for us to evaluate?
Answering your question, in Drools 4, assuming your facts are beans, there should be
almost no reason for you to fall back into an eval. The usage of eval is usually related
to the need for calculation inside a constraint or the call of functions.
[]s
Edson
2008/4/24 Bagwell, Allen F <afbagwe@sandia.gov<mailto:afbagwe@sandia.gov>>:
I'm learning how to use Drools, but eval presents a problem to me when I am composing
rules. I've read the manual and have a basic understanding of what it is for (very
useful in certain situations!), but is there a better explanation of when it cannot be
avoided?
For example when writing the LHS portion of a rule, I've run into a problem where
literal restrictions alone are fine for one object but inadequate for another. Like so:
$a : X(temp < 100)
$b : Y(running == true)
In both cases class X and class Y have standard Java bean set up for these fields with
appropriate getters and setters, and the corresponding inserted facts see these fields
being updated from time to time. But whereas the first fact causes rule activation when
the temp field meets the rule critiera, the second will never work unless it is re-written
as:
$b : Y()
eval ($b.isRunning() == true)
I've encountered a similar problem with in-line evals where Drools will accept an LHS
like this:
// attempting to find all applicants named Bob
$p : Person(firstName == "Bob")
$ap : Applicant(person == $p)
but it will never cause activation unless you re-write it like this:
$p : Person(firstName == "Bob")
$ap : Applicant( eval(person == $p) )
despite the fact that the Applicant object's person field once set never changes.
So is there a more definitive explanation as to why one is forced to use eval when you
would think that simple literal restrictions would be enough? I've read in other
posts that "eval is evil" and to best avoid it unless necessary, but this is
perplexing me because I haven't yet discovered the way to think about rule composition
that prevents eval use from appearing to be arbitrary. Mostly it's been write what I
think *should* work and if it does then great, it if doesn't then keep adding evals
until it does. For the record, I'm using the java dialect if that makes a difference.
Thanks!
-Allen
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com<http://www.jboss.com>
11:40 a.m.
I forgot to mention...
Drools 4.0.4 (the pre-compiled jars downloaded from the Drools web site)
Running on HP ProLiant/RedHat Enterprise 4.
-A
________________________________
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On
Behalf Of Edson Tirelli
Sent: Thursday, April 24, 2008 3:54 PM
To: Rules Users List
Subject: Re: [rules-users] When is eval unavoidable?
Allen,
Both your examples must work just fine:
$b : Y(running == true)
// attempting to find all applicants named Bob
$p : Person(firstName == "Bob")
$ap : Applicant(person == $p)
I can't think about a reason for them to not work. If they aren't, can you
please provide a self contained test case for us to evaluate?
Answering your question, in Drools 4, assuming your facts are beans, there should be
almost no reason for you to fall back into an eval. The usage of eval is usually related
to the need for calculation inside a constraint or the call of functions.
[]s
Edson
2008/4/24 Bagwell, Allen F <afbagwe@sandia.gov<mailto:afbagwe@sandia.gov>>:
I'm learning how to use Drools, but eval presents a problem to me when I am composing
rules. I've read the manual and have a basic understanding of what it is for (very
useful in certain situations!), but is there a better explanation of when it cannot be
avoided?
For example when writing the LHS portion of a rule, I've run into a problem where
literal restrictions alone are fine for one object but inadequate for another. Like so:
$a : X(temp < 100)
$b : Y(running == true)
In both cases class X and class Y have standard Java bean set up for these fields with
appropriate getters and setters, and the corresponding inserted facts see these fields
being updated from time to time. But whereas the first fact causes rule activation when
the temp field meets the rule critiera, the second will never work unless it is re-written
as:
$b : Y()
eval ($b.isRunning() == true)
I've encountered a similar problem with in-line evals where Drools will accept an LHS
like this:
// attempting to find all applicants named Bob
$p : Person(firstName == "Bob")
$ap : Applicant(person == $p)
but it will never cause activation unless you re-write it like this:
$p : Person(firstName == "Bob")
$ap : Applicant( eval(person == $p) )
despite the fact that the Applicant object's person field once set never changes.
So is there a more definitive explanation as to why one is forced to use eval when you
would think that simple literal restrictions would be enough? I've read in other
posts that "eval is evil" and to best avoid it unless necessary, but this is
perplexing me because I haven't yet discovered the way to think about rule composition
that prevents eval use from appearing to be arbitrary. Mostly it's been write what I
think *should* work and if it does then great, it if doesn't then keep adding evals
until it does. For the record, I'm using the java dialect if that makes a difference.
Thanks!
-Allen
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com<http://www.jboss.com>
2:10 p.m.
Allen,
The problem is that you are making your methods "final". When you make
your methods final, the shadow proxy can't intercept them to ensure working
memory consistency. In your example, just removing the final modifier from
your methods make them work as expected.
If it is of any help, you can completely disable shadow facts by
following the instructions in the manual or in this post:
http://blog.athico.com/2008/02/shadow-facts-what-you-always-wanted-to.html
Also, the algorithm used in drools 5 will not require shadow facts
anymore.
The reason eval works in your example is that it bypass shadow facts.
[]s
Edson
2008/4/25 Bagwell, Allen F <afbagwe(a)sandia.gov>:
I forgot to mention...
Drools 4.0.4 (the pre-compiled jars downloaded from the Drools web site)
Running on HP ProLiant/RedHat Enterprise 4.
-A
------------------------------
*From:* rules-users-bounces(a)lists.jboss.org [mailto:
rules-users-bounces(a)lists.jboss.org] *On Behalf Of *Edson Tirelli
*Sent:* Thursday, April 24, 2008 3:54 PM
*To:* Rules Users List
*Subject:* Re: [rules-users] When is eval unavoidable?
Allen,
Both your examples must work just fine:
$b : Y(running == true)
// attempting to find all applicants named Bob
$p : Person(firstName == "Bob")
$ap : Applicant(person == $p)
I can't think about a reason for them to not work. If they aren't, can
you please provide a self contained test case for us to evaluate?
Answering your question, in Drools 4, assuming your facts are beans,
there should be almost no reason for you to fall back into an eval. The
usage of eval is usually related to the need for calculation inside a
constraint or the call of functions.
[]s
Edson
2008/4/24 Bagwell, Allen F <afbagwe(a)sandia.gov>:
> I'm learning how to use Drools, but eval presents a problem to me when I
> am composing rules. I've read the manual and have a basic understanding of
> what it is for (very useful in certain situations!), but is there a better
> explanation of when it cannot be avoided?
>
> For example when writing the LHS portion of a rule, I've run into a
> problem where literal restrictions alone are fine for one object but
> inadequate for another. Like so:
>
> $a : X(temp < 100)
>
> $b : Y(running == true)
>
> In both cases class X and class Y have standard Java bean set up for these
> fields with appropriate getters and setters, and the corresponding inserted
> facts see these fields being updated from time to time. But whereas the
> first fact causes rule activation when the temp field meets the rule
> critiera, the second will never work unless it is re-written as:
>
> $b : Y()
> eval ($b.isRunning() == true)
>
>
> I've encountered a similar problem with in-line evals where Drools will
> accept an LHS like this:
>
> // attempting to find all applicants named Bob
> $p : Person(firstName == "Bob")
> $ap : Applicant(person == $p)
>
> but it will never cause activation unless you re-write it like this:
>
> $p : Person(firstName == "Bob")
> $ap : Applicant( eval(person == $p) )
>
> despite the fact that the Applicant object's person field once set never
> changes.
>
> So is there a more definitive explanation as to why one is forced to use
> eval when you would think that simple literal restrictions would be enough?
> I've read in other posts that "eval is evil" and to best avoid it
unless
> necessary, but this is perplexing me because I haven't yet discovered the
> way to think about rule composition that prevents eval use from appearing to
> be arbitrary. Mostly it's been write what I think *should* work and if it
> does then great, it if doesn't then keep adding evals until it does. For the
> record, I'm using the java dialect if that makes a difference.
>
> Thanks!
>
> -Allen
>
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
8:11 a.m.
(Monday morning, back in the office.)
Ah, thanks! I took out the final keywords and sure enough, it works.
Read the page link you provided. Good info there. I hadn't really delved into shadow
facts much yet. Thanks for clearing this up!
:-)
-A
________________________________
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On
Behalf Of Edson Tirelli
Sent: Friday, April 25, 2008 1:11 PM
To: Rules Users List
Subject: Re: [rules-users] When is eval unavoidable?
Allen,
The problem is that you are making your methods "final". When you make your
methods final, the shadow proxy can't intercept them to ensure working memory
consistency. In your example, just removing the final modifier from your methods make them
work as expected.
If it is of any help, you can completely disable shadow facts by following the
instructions in the manual or in this post:
http://blog.athico.com/2008/02/shadow-facts-what-you-always-wanted-to.html
Also, the algorithm used in drools 5 will not require shadow facts anymore.
The reason eval works in your example is that it bypass shadow facts.
[]s
Edson
2008/4/25 Bagwell, Allen F <afbagwe@sandia.gov<mailto:afbagwe@sandia.gov>>:
I forgot to mention...
Drools 4.0.4 (the pre-compiled jars downloaded from the Drools web site)
Running on HP ProLiant/RedHat Enterprise 4.
-A
________________________________
From:
rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org>
[mailto:rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org>]
On Behalf Of Edson Tirelli
Sent: Thursday, April 24, 2008 3:54 PM
To: Rules Users List
Subject: Re: [rules-users] When is eval unavoidable?
Allen,
Both your examples must work just fine:
$b : Y(running == true)
// attempting to find all applicants named Bob
$p : Person(firstName == "Bob")
$ap : Applicant(person == $p)
I can't think about a reason for them to not work. If they aren't, can you
please provide a self contained test case for us to evaluate?
Answering your question, in Drools 4, assuming your facts are beans, there should be
almost no reason for you to fall back into an eval. The usage of eval is usually related
to the need for calculation inside a constraint or the call of functions.
[]s
Edson
2008/4/24 Bagwell, Allen F <afbagwe@sandia.gov<mailto:afbagwe@sandia.gov>>:
I'm learning how to use Drools, but eval presents a problem to me when I am composing
rules. I've read the manual and have a basic understanding of what it is for (very
useful in certain situations!), but is there a better explanation of when it cannot be
avoided?
For example when writing the LHS portion of a rule, I've run into a problem where
literal restrictions alone are fine for one object but inadequate for another. Like so:
$a : X(temp < 100)
$b : Y(running == true)
In both cases class X and class Y have standard Java bean set up for these fields with
appropriate getters and setters, and the corresponding inserted facts see these fields
being updated from time to time. But whereas the first fact causes rule activation when
the temp field meets the rule critiera, the second will never work unless it is re-written
as:
$b : Y()
eval ($b.isRunning() == true)
I've encountered a similar problem with in-line evals where Drools will accept an LHS
like this:
// attempting to find all applicants named Bob
$p : Person(firstName == "Bob")
$ap : Applicant(person == $p)
but it will never cause activation unless you re-write it like this:
$p : Person(firstName == "Bob")
$ap : Applicant( eval(person == $p) )
despite the fact that the Applicant object's person field once set never changes.
So is there a more definitive explanation as to why one is forced to use eval when you
would think that simple literal restrictions would be enough? I've read in other
posts that "eval is evil" and to best avoid it unless necessary, but this is
perplexing me because I haven't yet discovered the way to think about rule composition
that prevents eval use from appearing to be arbitrary. Mostly it's been write what I
think *should* work and if it does then great, it if doesn't then keep adding evals
until it does. For the record, I'm using the java dialect if that makes a difference.
Thanks!
-Allen
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com<http://www.jboss.com>
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com<http://www.jboss.com>
6053
days inactive
6057
days old
5 comments
2 participants
participants (2)
-
Bagwell, Allen F -
Edson Tirelli