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 <ringsah@comcast.net>
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" <tirelli@post.com>

   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 <ringsah@comcast.net>

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
rules-users@lists.jboss.org
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: ringsah@comcast.net
To: Rules Users List <rules-users@lists.jboss.org>
Date: Mon, 04 Aug 2008 13:49:37 +0000
Subject: Re: [rules-users] "Not" Non-Existential Quantifier


---------- Mensagem encaminhada ----------
From: "Edson Tirelli" <tirelli@post.com>
To: "Rules Users List" <rules-users@lists.jboss.org>
Date: Thu, 31 Jul 2008 17:41:39 +0000
Subject: Re: [rules-users] "Not" Non-Existential Quantifier
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users




--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com