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

[Wolfgang Laun]

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 at 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20101123/05c98667/attachment.html