8:54 p.m.
To demonstrate the issue I have simplified the following sample rule to
just the components needed to demonstrate the issue. The example rule
I'm posting here uses the "after" operator; I have also tried this same
test with the before operator. In this sample the rule named "AfterRule"
will activate if the facts are initially inserted in a state matching
the pattern. However, if the facts are inserted in a state that does not
match, and then later updated to match the pattern using
StatefulKnowledgeSession.update() the rule will not activate.
Consider the following DRL:
package test.rules;
dialect "java"
import java.util.Date;
import com.p1s.mps.model.RuleTime;
import com.p1s.mps.model.Patient;
declare RuleTime
@role( event )
@timestamp( time )
end
declare Patient
@role( event )
@timestamp( birthDate )
end
rule "AfterRule"
when
$now : RuleTime( )
Patient( this after $now )
then
System.out.println("after");
end
Separately in a unit test the following actions are performed:
1. Insert an instance of RuleTime into the session where time is
set to now.
2. Insert an instance of a patient into the session where the
birthdate is set to (now - 1 day). [This makes the birthdate in the past
so the rule does not activate]
3. Call fireAllRules(). The rule does not activate, as expected.
4. Modify the patient instance to have a birthdate set to (now + 1
day).
5. Invoke update() on knowledge session.
6. Call fireAllRules(). The rules does not activate. It should
activate here.
If I change step 5 to a retract + insert then the rule will activate in
step 6 as expected.
Thank You,
Nathan Bell
9:54 p.m.
I believe the documentation mentions this: events are supposed to
be immutable, except for data enrichment. Timestamp is cloned at the
moment an event is inserted into the session to prevent inconsistent
reasoning (you know, in case a creative user tries to modify the
timestamp field... ;) ).
Besides that, Patient is an odd name for an event class, so either
there is a misunderstanding here, or you are using the wrong tool for
the job. If Patient is just a regular entity in your domain model, it
should not be declared as an event. Remember that you can use
point-in-time temporal operators (before, after, coincides) with any
Date/long attribute, no need to declare the class as an event class:
Patient( birthdate after $someTimestamp )
If you do that, you will be able to modify patient instances and
rules will behave correctly.
Try this:
http://blog.athico.com/2010/07/events-to-be-or-not-to-be-that-is.html
Edson
2010/11/22 Nathan Bell <Nathan.Bell(a)pharmacyonesource.com>:
To demonstrate the issue I have simplified the following sample rule
to just
the components needed to demonstrate the issue. The example rule I’m posting
here uses the “after” operator; I have also tried this same test with the
before operator. In this sample the rule named “AfterRule” will activate if
the facts are initially inserted in a state matching the pattern. However,
if the facts are inserted in a state that does not match, and then later
updated to match the pattern using StatefulKnowledgeSession.update() the
rule will not activate.
Consider the following DRL:
package test.rules;
dialect "java"
import java.util.Date;
import com.p1s.mps.model.RuleTime;
import com.p1s.mps.model.Patient;
declare RuleTime
@role( event )
@timestamp( time )
end
declare Patient
@role( event )
@timestamp( birthDate )
end
rule "AfterRule"
when
$now : RuleTime( )
Patient( this after $now )
then
System.out.println("after");
end
Separately in a unit test the following actions are performed:
1. Insert an instance of RuleTime into the session where time is set
to now.
2. Insert an instance of a patient into the session where the
birthdate is set to (now – 1 day). [This makes the birthdate in the past so
the rule does not activate]
3. Call fireAllRules(). The rule does not activate, as expected.
4. Modify the patient instance to have a birthdate set to (now + 1
day).
5. Invoke update() on knowledge session.
6. Call fireAllRules(). The rules does not activate. It should
activate here.
If I change step 5 to a retract + insert then the rule will activate in step
6 as expected.
Thank You,
Nathan Bell
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
1:07 a.m.
There may be very good reasons to have Patient with @role(event).
But for testing rules with temporal operators I find it much easier to
use a pseudo-clock for telling the Session about "now".
Also, a rule with a timer, inserting events with a very short expiry time
provides a very good way of producing ticks, discrete moments in
time, with which it is easy to reason.
-W
On 23 November 2010 04:54, Edson Tirelli <tirelli(a)post.com> wrote:
I believe the documentation mentions this: events are supposed to
be immutable, except for data enrichment. Timestamp is cloned at the
moment an event is inserted into the session to prevent inconsistent
reasoning (you know, in case a creative user tries to modify the
timestamp field... ;) ).
Besides that, Patient is an odd name for an event class, so either
there is a misunderstanding here, or you are using the wrong tool for
the job. If Patient is just a regular entity in your domain model, it
should not be declared as an event. Remember that you can use
point-in-time temporal operators (before, after, coincides) with any
Date/long attribute, no need to declare the class as an event class:
Patient( birthdate after $someTimestamp )
If you do that, you will be able to modify patient instances and
rules will behave correctly.
Try this:
http://blog.athico.com/2010/07/events-to-be-or-not-to-be-that-is.html
Edson
2010/11/22 Nathan Bell <Nathan.Bell(a)pharmacyonesource.com>:
> To demonstrate the issue I have simplified the following sample rule to
just
> the components needed to demonstrate the issue. The example rule I’m
posting
> here uses the “after” operator; I have also tried this same test with the
> before operator. In this sample the rule named “AfterRule” will activate
if
> the facts are initially inserted in a state matching the pattern.
However,
> if the facts are inserted in a state that does not match, and then later
> updated to match the pattern using StatefulKnowledgeSession.update() the
> rule will not activate.
>
>
>
> Consider the following DRL:
>
>
>
> package test.rules;
>
>
>
> dialect "java"
>
>
>
> import java.util.Date;
>
> import com.p1s.mps.model.RuleTime;
>
> import com.p1s.mps.model.Patient;
>
>
>
> declare RuleTime
>
> @role( event )
>
> @timestamp( time )
>
> end
>
>
>
> declare Patient
>
> @role( event )
>
> @timestamp( birthDate )
>
> end
>
>
>
> rule "AfterRule"
>
> when
>
> $now : RuleTime( )
>
> Patient( this after $now )
>
> then
>
> System.out.println("after");
>
> end
>
>
>
>
>
> Separately in a unit test the following actions are performed:
>
> 1. Insert an instance of RuleTime into the session where time is
set
> to now.
>
> 2. Insert an instance of a patient into the session where the
> birthdate is set to (now – 1 day). [This makes the birthdate in the past
so
> the rule does not activate]
>
> 3. Call fireAllRules(). The rule does not activate, as expected.
>
> 4. Modify the patient instance to have a birthdate set to (now + 1
> day).
>
> 5. Invoke update() on knowledge session.
>
> 6. Call fireAllRules(). The rules does not activate. It should
> activate here.
>
>
>
>
>
> If I change step 5 to a retract + insert then the rule will activate in
step
> 6 as expected.
>
>
>
>
>
> Thank You,
>
> Nathan Bell
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
12:10 p.m.
Edson,
You are right to say that in our domain model Patient is a regular entity and not an
event. And, yes, I have read that blog post you referenced, and actually discussed events
with you in person briefly at the San Diego conference this year. The only reason I
declared patient as an event was because I thought that the use of temporal operators
required declaring the object as an event. I've just skimmed the Fusion documentation
again to see if I missed where this was called out, but did not find it. Perhaps this
could be considered for a documentation enhancement?
Thank You,
Nathan Bell
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On
Behalf Of Edson Tirelli
Sent: Monday, November 22, 2010 7:55 PM
To: Rules Users List
Subject: Re: [rules-users] Temporal constraint not causing rule activation when using
StatefulKnowledgeSession.update()
I believe the documentation mentions this: events are supposed to
be immutable, except for data enrichment. Timestamp is cloned at the
moment an event is inserted into the session to prevent inconsistent
reasoning (you know, in case a creative user tries to modify the
timestamp field... ;) ).
Besides that, Patient is an odd name for an event class, so either
there is a misunderstanding here, or you are using the wrong tool for
the job. If Patient is just a regular entity in your domain model, it
should not be declared as an event. Remember that you can use
point-in-time temporal operators (before, after, coincides) with any
Date/long attribute, no need to declare the class as an event class:
Patient( birthdate after $someTimestamp )
If you do that, you will be able to modify patient instances and
rules will behave correctly.
Try this:
http://blog.athico.com/2010/07/events-to-be-or-not-to-be-that-is.html
Edson
2010/11/22 Nathan Bell <Nathan.Bell(a)pharmacyonesource.com>:
To demonstrate the issue I have simplified the following sample rule
to just
the components needed to demonstrate the issue. The example rule I'm posting
here uses the "after" operator; I have also tried this same test with the
before operator. In this sample the rule named "AfterRule" will activate if
the facts are initially inserted in a state matching the pattern. However,
if the facts are inserted in a state that does not match, and then later
updated to match the pattern using StatefulKnowledgeSession.update() the
rule will not activate.
Consider the following DRL:
package test.rules;
dialect "java"
import java.util.Date;
import com.p1s.mps.model.RuleTime;
import com.p1s.mps.model.Patient;
declare RuleTime
@role( event )
@timestamp( time )
end
declare Patient
@role( event )
@timestamp( birthDate )
end
rule "AfterRule"
when
$now : RuleTime( )
Patient( this after $now )
then
System.out.println("after");
end
Separately in a unit test the following actions are performed:
1. Insert an instance of RuleTime into the session where time is set
to now.
2. Insert an instance of a patient into the session where the
birthdate is set to (now - 1 day). [This makes the birthdate in the past so
the rule does not activate]
3. Call fireAllRules(). The rule does not activate, as expected.
4. Modify the patient instance to have a birthdate set to (now + 1
day).
5. Invoke update() on knowledge session.
6. Call fireAllRules(). The rules does not activate. It should
activate here.
If I change step 5 to a retract + insert then the rule will activate in step
6 as expected.
Thank You,
Nathan Bell
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
9:02 a.m.
Hi Nathan,
Yes, can you please open a JIRA for us to improve the documentation
on this aspect?
Sorry, sometimes I am bad at associating names to faces... :)
Edson
2010/11/23 Nathan Bell <Nathan.Bell(a)pharmacyonesource.com>:
Edson,
You are right to say that in our domain model Patient is a regular entity and not an
event. And, yes, I have read that blog post you referenced, and actually discussed events
with you in person briefly at the San Diego conference this year. The only reason I
declared patient as an event was because I thought that the use of temporal operators
required declaring the object as an event. I've just skimmed the Fusion documentation
again to see if I missed where this was called out, but did not find it. Perhaps this
could be considered for a documentation enhancement?
Thank You,
Nathan Bell
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On
Behalf Of Edson Tirelli
Sent: Monday, November 22, 2010 7:55 PM
To: Rules Users List
Subject: Re: [rules-users] Temporal constraint not causing rule activation when using
StatefulKnowledgeSession.update()
I believe the documentation mentions this: events are supposed to
be immutable, except for data enrichment. Timestamp is cloned at the
moment an event is inserted into the session to prevent inconsistent
reasoning (you know, in case a creative user tries to modify the
timestamp field... ;) ).
Besides that, Patient is an odd name for an event class, so either
there is a misunderstanding here, or you are using the wrong tool for
the job. If Patient is just a regular entity in your domain model, it
should not be declared as an event. Remember that you can use
point-in-time temporal operators (before, after, coincides) with any
Date/long attribute, no need to declare the class as an event class:
Patient( birthdate after $someTimestamp )
If you do that, you will be able to modify patient instances and
rules will behave correctly.
Try this:
http://blog.athico.com/2010/07/events-to-be-or-not-to-be-that-is.html
Edson
2010/11/22 Nathan Bell <Nathan.Bell(a)pharmacyonesource.com>:
> To demonstrate the issue I have simplified the following sample rule to just
> the components needed to demonstrate the issue. The example rule I'm posting
> here uses the "after" operator; I have also tried this same test with the
> before operator. In this sample the rule named "AfterRule" will activate
if
> the facts are initially inserted in a state matching the pattern. However,
> if the facts are inserted in a state that does not match, and then later
> updated to match the pattern using StatefulKnowledgeSession.update() the
> rule will not activate.
>
>
>
> Consider the following DRL:
>
>
>
> package test.rules;
>
>
>
> dialect "java"
>
>
>
> import java.util.Date;
>
> import com.p1s.mps.model.RuleTime;
>
> import com.p1s.mps.model.Patient;
>
>
>
> declare RuleTime
>
> @role( event )
>
> @timestamp( time )
>
> end
>
>
>
> declare Patient
>
> @role( event )
>
> @timestamp( birthDate )
>
> end
>
>
>
> rule "AfterRule"
>
> when
>
> $now : RuleTime( )
>
> Patient( this after $now )
>
> then
>
> System.out.println("after");
>
> end
>
>
>
>
>
> Separately in a unit test the following actions are performed:
>
> 1. Insert an instance of RuleTime into the session where time is set
> to now.
>
> 2. Insert an instance of a patient into the session where the
> birthdate is set to (now - 1 day). [This makes the birthdate in the past so
> the rule does not activate]
>
> 3. Call fireAllRules(). The rule does not activate, as expected.
>
> 4. Modify the patient instance to have a birthdate set to (now + 1
> day).
>
> 5. Invoke update() on knowledge session.
>
> 6. Call fireAllRules(). The rules does not activate. It should
> activate here.
>
>
>
>
>
> If I change step 5 to a retract + insert then the rule will activate in step
> 6 as expected.
>
>
>
>
>
> Thank You,
>
> Nathan Bell
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
9:58 a.m.
Just added a comment to my collective JIRA JBRULES-2785 for a bundle
of documentation fixes.
Nathan, no need to create another JIRA.
-W
On 24 November 2010 16:02, Edson Tirelli <tirelli(a)post.com> wrote:
Hi Nathan,
Yes, can you please open a JIRA for us to improve the documentation
on this aspect?
Sorry, sometimes I am bad at associating names to faces... :)
Edson
2010/11/23 Nathan Bell <Nathan.Bell(a)pharmacyonesource.com>:
> Edson,
>
> You are right to say that in our domain model Patient is a regular entity and not an
event. And, yes, I have read that blog post you referenced, and actually discussed events
with you in person briefly at the San Diego conference this year. The only reason I
declared patient as an event was because I thought that the use of temporal operators
required declaring the object as an event. I've just skimmed the Fusion documentation
again to see if I missed where this was called out, but did not find it. Perhaps this
could be considered for a documentation enhancement?
>
> Thank You,
>
> Nathan Bell
>
>
> -----Original Message-----
> From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Edson Tirelli
> Sent: Monday, November 22, 2010 7:55 PM
> To: Rules Users List
> Subject: Re: [rules-users] Temporal constraint not causing rule activation when using
StatefulKnowledgeSession.update()
>
>
> I believe the documentation mentions this: events are supposed to
> be immutable, except for data enrichment. Timestamp is cloned at the
> moment an event is inserted into the session to prevent inconsistent
> reasoning (you know, in case a creative user tries to modify the
> timestamp field... ;) ).
>
> Besides that, Patient is an odd name for an event class, so either
> there is a misunderstanding here, or you are using the wrong tool for
> the job. If Patient is just a regular entity in your domain model, it
> should not be declared as an event. Remember that you can use
> point-in-time temporal operators (before, after, coincides) with any
> Date/long attribute, no need to declare the class as an event class:
>
> Patient( birthdate after $someTimestamp )
>
> If you do that, you will be able to modify patient instances and
> rules will behave correctly.
>
> Try this:
>
> http://blog.athico.com/2010/07/events-to-be-or-not-to-be-that-is.html
>
> Edson
>
>
>
> 2010/11/22 Nathan Bell <Nathan.Bell(a)pharmacyonesource.com>:
>> To demonstrate the issue I have simplified the following sample rule to just
>> the components needed to demonstrate the issue. The example rule I'm posting
>> here uses the "after" operator; I have also tried this same test with
the
>> before operator. In this sample the rule named "AfterRule" will
activate if
>> the facts are initially inserted in a state matching the pattern. However,
>> if the facts are inserted in a state that does not match, and then later
>> updated to match the pattern using StatefulKnowledgeSession.update() the
>> rule will not activate.
>>
>>
>>
>> Consider the following DRL:
>>
>>
>>
>> package test.rules;
>>
>>
>>
>> dialect "java"
>>
>>
>>
>> import java.util.Date;
>>
>> import com.p1s.mps.model.RuleTime;
>>
>> import com.p1s.mps.model.Patient;
>>
>>
>>
>> declare RuleTime
>>
>> @role( event )
>>
>> @timestamp( time )
>>
>> end
>>
>>
>>
>> declare Patient
>>
>> @role( event )
>>
>> @timestamp( birthDate )
>>
>> end
>>
>>
>>
>> rule "AfterRule"
>>
>> when
>>
>> $now : RuleTime( )
>>
>> Patient( this after $now )
>>
>> then
>>
>> System.out.println("after");
>>
>> end
>>
>>
>>
>>
>>
>> Separately in a unit test the following actions are performed:
>>
>> 1. Insert an instance of RuleTime into the session where time is set
>> to now.
>>
>> 2. Insert an instance of a patient into the session where the
>> birthdate is set to (now - 1 day). [This makes the birthdate in the past so
>> the rule does not activate]
>>
>> 3. Call fireAllRules(). The rule does not activate, as expected.
>>
>> 4. Modify the patient instance to have a birthdate set to (now + 1
>> day).
>>
>> 5. Invoke update() on knowledge session.
>>
>> 6. Call fireAllRules(). The rules does not activate. It should
>> activate here.
>>
>>
>>
>>
>>
>> If I change step 5 to a retract + insert then the rule will activate in step
>> 6 as expected.
>>
>>
>>
>>
>>
>> Thank You,
>>
>> Nathan Bell
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>
>
>
> --
> Edson Tirelli
> JBoss Drools Core Development
> JBoss by Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5116
days inactive
5117
days old
5 comments
3 participants
participants (3)
-
Edson Tirelli -
Nathan Bell -
Wolfgang Laun