Okay, I understand now. I had incorrectly assumed that the "applicant ==
$applicant" constraint was using identity. Not a big deal to work around. It
seems like you would most often want to use identity in constraints, but I
guess you have to provide for those cases when you need to use equality. Maybe
there should be two different operators. Just my two ยข.
Anyway, thanks.
-Hans
-------------- Original message --------------
From: "Edson Tirelli" <[EMAIL PROTECTED]>
Oh, I see.
Unfortunately in this case, there is nothing we can do about it, because the
rules are behaving exactly as they were supposed to behave:
NegativeResult(applicant == $applicant)
As you can see, they are telling the application to use the equals
comparison in the constraint:
applicant == $applicant
A fact should not change it's identity once it is asserted, so, either you
use a constant "equals()/hashcode()" implementation, or you use constraints on
an immutable ID:
NegativeResult(applicantId == $applicant.id)
You can also fallback to java "identity" check by using eval, but it is
ugly... :)
NegativeResult( eval( applicant == $applicant) )
[]s
Edson
2008/8/4 <[EMAIL PROTECTED]>
Edson,
I finally succeeded in coming up with a simple test case that shows the
problem. I have attached the necessary files, which include a test case, three
fact objects, and the drl.
One key to this test are the fact that the Applicant fact object has an
"equals" method that tests for equality of its attributes, rather than
identity. A second key is that the applicant object is updated after it is
inserted.
It appears that what is happening is that an activation is created for the rule
that uses "not" when the applicant is inserted. Then, when the applicant is
updated, a second activation is created for that rule. It should be cancelling
the previous activation, but doesn't find it because the Applicant instance no
longer "equals" the fact object that caused the activation.
Thanks!
-Hans
-------------- Original message --------------
From: "Edson Tirelli" <[EMAIL PROTECTED]>
Hans,
Your reasoning is correct. There should not be 2 instances of
ApplicantStatus in the working memory.
Can you provide a test case showing the problem? we have test cases here
using "not" and logical assertions, and it works properly.
Thanks,
Edson
2008/7/31 <[EMAIL PROTECTED]>
How is "
not" supposed to work with insertLogical? Assume I have two different rules
whose conditions are mutually exclusive, like the following:
rule
"Rule One"
when
not NegativeResult()
then
insertLogical(new ApplicantStatus("Approved"));
end
rule
"Rule Two"
when
NegativeResult()
then
insertLogical(new ApplicantStatus("Denied"));
end
Assume that the above two rules are the only way an
ApplicantStatus fact can be inserted into working memory. I would expect, after
all rules are run, that it would be impossible for there to be one
ApplicantStatus with "Approved" as its reason, and another with "Denied" as its
reason, in the working memory.
I would expect that, before any
NegativeResult is inserted, that rule one could run, and insert an
ApplicantStatus fact with an "Approved" reason. Then, after a NegativeResult is
inserted, that rule two could run, and insert an ApplicantStatus fact with a
"Denied" reason. At this point I would expect that the original ApplicantStatus
fact, with an "Approved" reason, would be retracted, since the conditions under
which it was inserted are no lon! ger true.
This is not what I am observing, however. I am finding
ApplicantStatus facts with both reasons in working memory at the end of the
rules run. Should "not" work as I expect with regard to inserting a fact via
insertLogical()? Or is this a known limitation, or simply the way it is
designed to work?
Thanks,
-Hans
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
---------- Mensagem encaminhada ----------
From: [EMAIL PROTECTED]
To: Rules Users List <[email protected]>
Date: Mon, 04 Aug 2008 13:49:37 +0000
Subject: Re: [rules-users] "Not" Non-Existential Quantifier
---------- Mensagem encaminhada ----------
From: "Edson Tirelli" <[EMAIL PROTECTED]>
To: "Rules Users List" <[email protected]>
Date: Thu, 31 Jul 2008 17:41:39 +0000
Subject: Re: [rules-users] "Not" Non-Existential Quantifier
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com--- Begin Message ---
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
--- End Message ---
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
