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

[Wolfgang Laun]

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