Re: [rules-users] Not Non-Existential Quantifier
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 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---BeginMessage--- ---BeginMessage--- ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ---End Message--- Applicant.java Description: Binary data ApplicantStatus.java Description: Binary data NegativeResult.java Description: Binary data notTest.drl Description: Binary data ---End Message--- NotTest.java Description: Binary data ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
RE: [rules-users] Not Non-Existential Quantifier
How is your rule base configured, with identity or equality assert behavior? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, August 04, 2008 9:59 AM To: Rules Users List Subject: Re: [rules-users] Not Non-Existential Quantifier 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 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 http://www.jboss.com/ ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
RE: [rules-users] Not Non-Existential Quantifier
The default - identity. -- Original message -- From: Fenderbosch, Eric [EMAIL PROTECTED] How is your rule base configured, with identity or equality assert behavior? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, August 04, 2008 9:59 AM To: Rules Users List Subject: Re: [rules-users] Not Non-Existential Quantifier 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 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---BeginMessage--- ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ---End Message--- ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Not Non-Existential Quantifier
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 Deniedas 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: [EMAIL PROTECTED] To: Rules Users List rules-users@lists.jboss.org Date: Mon, 04 Aug 2008 13:49:37 + Subject: Re: [rules-users] Not Non-Existential Quantifier -- Mensagem encaminhada -- From: Edson Tirelli [EMAIL PROTECTED] To: Rules Users List rules-users@lists.jboss.org Date: Thu, 31 Jul 2008 17:41:39 + 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 ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Not Non-Existential Quantifier
Eric, Unfortunately, in his case does not matter if he is using identity or equality behavior, because the problem is in the constraint, that is telling the engine to use equals(): applicant == $applicant []s Edson 2008/8/4 Fenderbosch, Eric [EMAIL PROTECTED] How is your rule base configured, with identity or equality assert behavior? -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of [EMAIL PROTECTED] *Sent:* Monday, August 04, 2008 9:59 AM *To:* Rules Users List *Subject:* Re: [rules-users] Not Non-Existential Quantifier 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 Deniedas 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 ___ 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 ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Not Non-Existential Quantifier
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 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: [EMAIL PROTECTED] To: Rules Users List rules-users@lists.jboss.org Date: Mon, 04 Aug 2008 13:49:37 + Subject: Re: [rules-users] Not Non-Existential Quantifier -- Mensagem encaminhada -- From: Edson Tirelli [EMAIL PROTECTED] To: Rules Users List rules-users@lists.jboss.org Date: Thu, 31 Jul 2008 17:41:39 + 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---BeginMessage
Re: [rules-users] Not Non-Existential Quantifier
Hans, If you change not NegativeResult() to not (exits NegativeResult()) this should result in the expected behaviour. Cheers, Ingomar Am 31.07.2008 um 17:19 schrieb [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 longer 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 ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Not Non-Existential Quantifier
Ingomar, I tried this, and indeed that worked. I was surprised, as I thought not was meant more to mean that a fact inside its parentheses did not exist, rather than a logical negation, which is the way you used it in your example. However, if I do what you said, it does work exactly how I expected not alone to work. Thanks! -Hans -- Original message -- From: Ingomar Otter [EMAIL PROTECTED] Hans, If you change not NegativeResult() to not (exits NegativeResult()) this should result in the expected behaviour. Cheers, Ingomar Am 31.07.2008 um 17:19 schrieb [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 longer 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 ___ 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
Re: [rules-users] Not Non-Existential Quantifier
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 Deniedas 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 longer 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 ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Not Non-Existential Quantifier
Hmm, in this case, it is definitively a bug. not IS the existential qualifier, i.e., the constrary of exists. So it should be simply redundant to write not exists. Need to investigate that. []s Edson 2008/7/31 [EMAIL PROTECTED] Ingomar, I tried this, and indeed that worked. I was surprised, as I thought not was meant more to mean that a fact inside its parentheses did not exist, rather than a logical negation, which is the way you used it in your example. However, if I do what you said, it does work exactly how I expected not alone to work. Thanks! -Hans -- Original message -- From: Ingomar Otter [EMAIL PROTECTED] Hans, If you change not NegativeResult() to not (exits NegativeResult()) this should result in the expected behaviour. Cheers, Ingomar Am 31.07.2008 um 17:19 schrieb [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 longer true. This is not what I am observin! g, howe ver. 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 ___ 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 ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Not Non-Existential Quantifier
Hans, I checked the docs and as Edson says it should work without the exists( ). Strange that never worked for me. Maybe we all learn something if you can carve out a test-case. Strange. --I Am 31.07.2008 um 19:29 schrieb [EMAIL PROTECTED]: Ingomar, I tried this, and indeed that worked. I was surprised, as I thought not was meant more to mean that a fact inside its parentheses did not exist, rather than a logical negation, which is the way you used it in your example. However, if I do what you said, it does work exactly how I expected not alone to work. Thanks! -Hans -- Original message -- From: Ingomar Otter [EMAIL PROTECTED] Hans, If you change not NegativeResult() to not (exits NegativeResult()) this should result in the expected behaviour. Cheers, Ingomar Am 31.07.2008 um 17:19 schrieb [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 longer 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 ___ 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 ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
