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@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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users