[rules-users] Temporal constraint not causing rule activation when using StatefulKnowledgeSession.update()

[Edson Tirelli]

   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 at 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 at lists.jboss.org [mailto:rules-users-bounces at 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 at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com