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