Re: [rules-users] "Not" Non-Existential Quantifier

2008-07-31 Thread Ingomar Otter

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

2008-07-31 Thread ringsah
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

2008-07-31 Thread Edson Tirelli
   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 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

2008-07-31 Thread Edson Tirelli
   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

2008-07-31 Thread Ingomar Otter

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


Re: [rules-users] "Not" Non-Existential Quantifier

2008-08-04 Thread ringsah
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--- Begin Message ---
--- Begin Message ---
___
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

2008-08-04 Thread Fenderbosch, Eric
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

2008-08-04 Thread ringsah
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--- Begin Message ---
___
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

2008-08-04 Thread Edson Tirelli
   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 
> 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" 
> 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

2008-08-04 Thread Edson Tirelli
   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 "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
>
>
> ___
> 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

2008-08-04 Thread ringsah
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 
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" 
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/r