[rules-users] MVEL interpretation
My team is using Drools on a government project. As is usually the case with government projects, the security folks have their hands in every aspect of the project. They have big questions on MVEL, but I'm going to try to boil them down to one simple question: At what stage(s) of Drools's lifecycle does MVEL interpretation occur? I think that the compilation engine interprets the MVEL at compile time and converts it to generated Java code, though I don't know enough about the internals of the engine to say for sure. Stated another way, does Drools interpret rules written using the MVEL dialect at runtime? Thanks Mike ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] NPE in FireAllRulesCommand (bug?)
JBRULES-3421 created and pull request submitted with fix and tests.
On Fri, Mar 2, 2012 at 1:57 PM, Mike Melton mike.mel...@gmail.com wrote:
Drools 5.3.1.Final.
I have a use case where I am executing a BatchExecutionCommand against a
stateless session. One of the sub-commands is a FireAllRulesCommand, from
which I would like to retrieve the number of rules actually fired. Since
there is no factory or constructor method to configure both a maximum rules
to fire and an out identifier, I have to use code like this to set up
my FireAllRulesCommand:
FireAllRulesCommand farc = (FireAllRulesCommand)
CommandFactory.newFireAllRules(maxRulesToFire);
farc.setOutIdentifier(num-rules-fired);
commands.add(farc); // commands is ListCommand? which I later use to
construct a BatchExecutionCommand
At runtime, when I execute the BatchExecutionCommand, I get an NPE
at FireAllRulesCommand:110. After some investigating, I determined that the
value returned from (ExecutionResultImpl) ((KnowledgeCommandContext)
context).getExecutionResults() is null, which causes the NPE.
As far as I can tell, the cause of this breaks down like so:
- StatelessKnowledgeSession.execute() fires with the batch command as
input.
- It constructs a KnowledgeCommandContext, setting the ExecutionResults
parameter of the constructor to null (line 254).
- KnowledgeCommandContext.executionResults is a private member with no
setter so there is no way to give it a value after it's been instantiated.
- The FireAllRulesCommand fires as part of the batch, and when it tries to
access the execution results from the context, the NPE is thrown.
StatelessKnowledgeSession.execute() later gets the execution results from
the session itself, via the ExecutionResultsImpl instance which is
constructed and passed to the startBatchExecution() method on line 262. I
haven't had time to try this myself, but if we constructed
the ExecutionResultsImpl earlier and passed it to both
the KnowledgeCommandContext constructor and the startBatchExecution()
method, would the problem be alleviated?
In other words, something like this
(StatelessKnowledgeSessionImpl.java:251):
public T T execute(CommandT command) {
StatefulKnowledgeSession ksession = newWorkingMemory();
ExecutionResults results = new ExecutionResultImpl();
KnowledgeCommandContext context = new KnowledgeCommandContext( new
ContextImpl( ksession,
null ),
null,
null,
ksession,
results
);
try {
((StatefulKnowledgeSessionImpl)
ksession).session.startBatchExecution( results );
If this is indeed a bug and not something silly I'm missing, I'll be happy
to submit a JIRA and even a pull request with the fix.
Thanks
Mike
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Avoid propagation of update in a then block.
Let the rule engine do what it does best. You are fighting against the
optimizations of the engine by trying to control the flow. You can rewrite
your rule as
rule my-rule
when
$entity : Entity( closed == false )
then
modify($entity) { setClosed(true); }
end
The rule will fire (once) for each Entity which matches the condition. I
haven't taken the time to apply the same exercise to your more complex
rule, but a general rule you should abide by is No looping in the
consequence unless I have a really good reason.
Mike
2012/3/13 Patrik Dufresne ikus...@gmail.com
Hi,
I have some trouble to figure out how to stop / start the propagation of
updates within a Then block.
Here is a snippet to represent the problem I have.
rule my-rule
when
$objects : List()
from accumulate( $entity : Entity(closed==false),
collectList($entity) )
then
for(Object obj : $objects) {
((Entity) obj).setClosed(true);
update(obj);
}
end
When this rule's consequence is called first, the first enity in the list
is 'update', but then update if propagated to immediately causing the rule
to be evaluated with all the entities minus the updated one. So I'm
wondering if there is a transaction like operation allowing me to update
all the entities in the list and then fire the rules.
According to the documentation no-loop should have help me for this.
Here is the original rules
rule close-shift
salience -1
when
$shift : Shift( )
$assignments : List( size 0 )
from accumulate (
$assignment : PlanifEventAssignment(
close == false,
shift == $shift ),
collectList($assignment) )
$availables : List( size = $assignments.size )
from accumulate ( ( and
ShiftAssignment(
shift == $shift,
$employee : employee)
$available : EmployeeAvailable (
employee == $employee,
assignment.shift == $shift) ),
collectList($available) )
eval( Dfs.search($assignments, $availables) != null )
then
// Recalculate the result.
Map table = Dfs.search($assignments, $availables);
for(Object entry : table.entrySet()) {
PlanifEventAssignment assignment =
(PlanifEventAssignment)((Entry)entry).getKey();
EmployeeValue employee = (EmployeeValue)((Entry)entry).getValue();
assignment.setClose(true);
assignment.setEmployee(employee);
update(assignment);
}
end
Patrik Dufresne
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Avoid propagation of update in a then block.
Sorry - I didn't have the time earlier to fully parse the more complex
rule. The problem you're having is that the engine reevaluates the
conditions on each working memory change, and since, as you noticed, the
list has changed, the rule fires again. The no-loop attribute prevents a
rule from reactivating itself with the current set of facts. You do not
have the same set of facts, and so no-loop is not applicable in your case.
It looks to me like you want to insert the results of the Dfs.search()
operation as a fact or list of facts, and then include a pattern in your
condition that prevents the rule from firing if these results exist in
working memory. You would then have another rule or set of rules that
process the results, retracting them as they go. Once all the results from
one firing of the accumulate rule have been processed and retracted, then
the accumulate rule would be free to fire again on the next set of data.
(An aside: since Dfs.search() returns a Map, you'll probably want to create
your own implementation since a rule with a pattern on Map() would evaluate
true for any map that happens to be in working memory. However, a rule
that's looking for DfsSearchResults would only match in your particular
case. Another (perhaps better) option is to use traits to have your Map
don a trait that your other rules can then reason on. Traits are still an
experiment feature but I've played with them and they are very cool.)
Before I ramble too much further, here is a very pseudocoded version of
what I'm talking about. I'm going to assume that Dfs.search() returns
something called DfsSearchResults; whether that type is an implementation
of Map or a trait is semi-irrelevant.
We're also going to assume a new type called DfsSearchResult:
declare DfsSearchResult
assignment : PlanifEventAssignment
employee : EmployeeValue
end
So your accumulate rule would be:
rule close-shift
when
not DfsSearchResult( ) // Keeps this rule from activating again until all
results of the previous firing are processed
$shift : Shift( )
$assignments : ... // this condition stays the same
$availables : ... // this condition stays the same too
$results : DfsSearchResults( size 0 ) from Dfs.search( $assignments,
$availables )
then
for ( DfsSearchResult dsr : $results ) { // the magic of pseudocode is it
doesn't compile and we don't care!
PlanifEventAssignment assignment = ...
EmployeeValue employee = ...
insert( new DfsSearchResult( assignment, employee ) );
}
end
And now you'll have a processing rule:
rule update-assignment
when
$dsr : DfsSearchResult( $a : assignment, $e : employee )
then
modify($a) { setClose(true); setEmployee($e); }
retract($dsr);
end
I think that will get you as least in the right direction. I hope this
helps.
Mike
P.S. Now that I think about it, I'd like to amend the guideline I wrote in
my last email: No looping in the consequence unless it is to decompose a
collection of data into simple facts that are much easier to reason over...
or if I have another really good reason.
2012/3/13 Patrik Dufresne ikus...@gmail.com
Hi Mike,
I see your point, it's very valid for the snippet rule, but can't be apply
to the real one since I need to run a function using eval().
Patrik Dufresne
On Tue, Mar 13, 2012 at 4:45 PM, Mike Melton mike.mel...@gmail.comwrote:
Let the rule engine do what it does best. You are fighting against the
optimizations of the engine by trying to control the flow. You can rewrite
your rule as
rule my-rule
when
$entity : Entity( closed == false )
then
modify($entity) { setClosed(true); }
end
The rule will fire (once) for each Entity which matches the condition. I
haven't taken the time to apply the same exercise to your more complex
rule, but a general rule you should abide by is No looping in the
consequence unless I have a really good reason.
Mike
2012/3/13 Patrik Dufresne ikus...@gmail.com
Hi,
I have some trouble to figure out how to stop / start the propagation of
updates within a Then block.
Here is a snippet to represent the problem I have.
rule my-rule
when
$objects : List()
from accumulate( $entity : Entity(closed==false),
collectList($entity) )
then
for(Object obj : $objects) {
((Entity) obj).setClosed(true);
update(obj);
}
end
When this rule's consequence is called first, the first enity in the
list is 'update', but then update if propagated to immediately causing the
rule to be evaluated with all the entities minus the updated one. So I'm
wondering if there is a transaction like operation allowing me to update
all the entities in the list and then fire the rules.
According to the documentation no-loop should have help me for this.
Here is the original rules
rule close-shift
salience -1
when
$shift : Shift( )
$assignments : List( size 0 )
from accumulate (
$assignment : PlanifEventAssignment
Re: [rules-users] Avoid propagation of update in a then block.
I just realized that I changed my mind on implementation mid-post and
misled you a bit. You do *not* need a special implementation of Map since
you are never reasoning over it; the accumulate rule consequence decomposes
the map results into DfsSearchResult facts. So replace any references to
DfsSearchResults above with Map.
Sorry for any confusion.
Mike
On Mar 13, 2012 10:12 PM, Mike Melton mike.mel...@gmail.com wrote:
Sorry - I didn't have the time earlier to fully parse the more complex
rule. The problem you're having is that the engine reevaluates the
conditions on each working memory change, and since, as you noticed, the
list has changed, the rule fires again. The no-loop attribute prevents a
rule from reactivating itself with the current set of facts. You do not
have the same set of facts, and so no-loop is not applicable in your case.
It looks to me like you want to insert the results of the Dfs.search()
operation as a fact or list of facts, and then include a pattern in your
condition that prevents the rule from firing if these results exist in
working memory. You would then have another rule or set of rules that
process the results, retracting them as they go. Once all the results from
one firing of the accumulate rule have been processed and retracted, then
the accumulate rule would be free to fire again on the next set of data.
(An aside: since Dfs.search() returns a Map, you'll probably want to
create your own implementation since a rule with a pattern on Map() would
evaluate true for any map that happens to be in working memory. However, a
rule that's looking for DfsSearchResults would only match in your
particular case. Another (perhaps better) option is to use traits to have
your Map don a trait that your other rules can then reason on. Traits are
still an experiment feature but I've played with them and they are very
cool.)
Before I ramble too much further, here is a very pseudocoded version of
what I'm talking about. I'm going to assume that Dfs.search() returns
something called DfsSearchResults; whether that type is an implementation
of Map or a trait is semi-irrelevant.
We're also going to assume a new type called DfsSearchResult:
declare DfsSearchResult
assignment : PlanifEventAssignment
employee : EmployeeValue
end
So your accumulate rule would be:
rule close-shift
when
not DfsSearchResult( ) // Keeps this rule from activating again until
all results of the previous firing are processed
$shift : Shift( )
$assignments : ... // this condition stays the same
$availables : ... // this condition stays the same too
$results : DfsSearchResults( size 0 ) from Dfs.search( $assignments,
$availables )
then
for ( DfsSearchResult dsr : $results ) { // the magic of pseudocode is
it doesn't compile and we don't care!
PlanifEventAssignment assignment = ...
EmployeeValue employee = ...
insert( new DfsSearchResult( assignment, employee ) );
}
end
And now you'll have a processing rule:
rule update-assignment
when
$dsr : DfsSearchResult( $a : assignment, $e : employee )
then
modify($a) { setClose(true); setEmployee($e); }
retract($dsr);
end
I think that will get you as least in the right direction. I hope this
helps.
Mike
P.S. Now that I think about it, I'd like to amend the guideline I wrote in
my last email: No looping in the consequence unless it is to decompose a
collection of data into simple facts that are much easier to reason over...
or if I have another really good reason.
2012/3/13 Patrik Dufresne ikus...@gmail.com
Hi Mike,
I see your point, it's very valid for the snippet rule, but can't be
apply to the real one since I need to run a function using eval().
Patrik Dufresne
On Tue, Mar 13, 2012 at 4:45 PM, Mike Melton mike.mel...@gmail.comwrote:
Let the rule engine do what it does best. You are fighting against the
optimizations of the engine by trying to control the flow. You can rewrite
your rule as
rule my-rule
when
$entity : Entity( closed == false )
then
modify($entity) { setClosed(true); }
end
The rule will fire (once) for each Entity which matches the condition. I
haven't taken the time to apply the same exercise to your more complex
rule, but a general rule you should abide by is No looping in the
consequence unless I have a really good reason.
Mike
2012/3/13 Patrik Dufresne ikus...@gmail.com
Hi,
I have some trouble to figure out how to stop / start the propagation
of updates within a Then block.
Here is a snippet to represent the problem I have.
rule my-rule
when
$objects : List()
from accumulate( $entity : Entity(closed==false),
collectList($entity) )
then
for(Object obj : $objects) {
((Entity) obj).setClosed(true);
update(obj);
}
end
When this rule's consequence is called first, the first enity in the
list is 'update', but then update
[rules-users] NPE in FireAllRulesCommand (bug?)
Drools 5.3.1.Final.
I have a use case where I am executing a BatchExecutionCommand against a
stateless session. One of the sub-commands is a FireAllRulesCommand, from
which I would like to retrieve the number of rules actually fired. Since
there is no factory or constructor method to configure both a maximum rules
to fire and an out identifier, I have to use code like this to set up
my FireAllRulesCommand:
FireAllRulesCommand farc = (FireAllRulesCommand)
CommandFactory.newFireAllRules(maxRulesToFire);
farc.setOutIdentifier(num-rules-fired);
commands.add(farc); // commands is ListCommand? which I later use to
construct a BatchExecutionCommand
At runtime, when I execute the BatchExecutionCommand, I get an NPE
at FireAllRulesCommand:110. After some investigating, I determined that the
value returned from (ExecutionResultImpl) ((KnowledgeCommandContext)
context).getExecutionResults() is null, which causes the NPE.
As far as I can tell, the cause of this breaks down like so:
- StatelessKnowledgeSession.execute() fires with the batch command as input.
- It constructs a KnowledgeCommandContext, setting the ExecutionResults
parameter of the constructor to null (line 254).
- KnowledgeCommandContext.executionResults is a private member with no
setter so there is no way to give it a value after it's been instantiated.
- The FireAllRulesCommand fires as part of the batch, and when it tries to
access the execution results from the context, the NPE is thrown.
StatelessKnowledgeSession.execute() later gets the execution results from
the session itself, via the ExecutionResultsImpl instance which is
constructed and passed to the startBatchExecution() method on line 262. I
haven't had time to try this myself, but if we constructed
the ExecutionResultsImpl earlier and passed it to both
the KnowledgeCommandContext constructor and the startBatchExecution()
method, would the problem be alleviated?
In other words, something like this
(StatelessKnowledgeSessionImpl.java:251):
public T T execute(CommandT command) {
StatefulKnowledgeSession ksession = newWorkingMemory();
ExecutionResults results = new ExecutionResultImpl();
KnowledgeCommandContext context = new KnowledgeCommandContext( new
ContextImpl( ksession,
null ),
null,
null,
ksession,
results
);
try {
((StatefulKnowledgeSessionImpl)
ksession).session.startBatchExecution( results );
If this is indeed a bug and not something silly I'm missing, I'll be happy
to submit a JIRA and even a pull request with the fix.
Thanks
Mike
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Session persistence
That's odd. We have stateful sessions persisted using the techniques shown in the documentation you link to, and rehydrated sessions are fully populated with all facts/events from working memory as expected. We have the same requirement (sessions must survive a server reboot 100% intact) and we have been quite pleased with the results. The only things we have to re-establish upon rehydration are globals and event listeners. We use JPAKnowledgeService.newStatefulKnowledgeSession(..) to establish new persisted sessions and JPAKnowledgeService.loadStatefulKnowledgeSession(..) to rehydrate existing persisted sessions. I doubt I've been much help to you but perhaps it will help to know that someone has seen persistence work as advertised. Mike 2012/2/20 Alberto R. Galdo arga...@gmail.com Hi, We are using Drools Expert, Fusion, Flow, etc... to build a complex event processing system and one of our main constraints is to be fault tolerant. As such, we are using an StatefulKnowledgeSession and our system involves processes, sets of rules, events, accumulators, ... . What we need is to be able to reconstruct a KnowledgeSession in a given state and all our changes in the knowledgesession need to be persisted at the very moment a change is detected. The documentation is sparse in this point ( http://docs.jboss.org/drools/release/5.4.0.Beta2/drools-expert-docs/html/ch04.html#d0e2702) and what we've seen so far is that our rules are persisted but no traces of facts or events ... This would be unaceptable for our product. We need to be able to stop our service at any time and restore the knowledge session at any time as it was at the moment of the previous stop. We have previous experience with JBPM 3 using a persistent storage to be fault tolerant and it works like a charm, we can see our processes, process instances, timers, etc... . Can we get a *full* KnowledgeSession persistence service for Drools? Greets, ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Possible bug with isA operator
I am having trouble getting the isA operator to work with POJO facts. The problem manifests in the IsAEvaluator.evaluate(...) method, line 163 (5.3.0.Final). This line checks whether the objectValue class is annotated with @Traitable. For a @Traitable fact fully declared in DRL, this line correctly evaluates to true. For a POJO fact which is declared @Traitable in DRL, this line evaluates to false. (I tried adding @Traitable to the POJO fact itself, which results in the line evaluating true, but the next line which casts to a TraitableBean fails.) I have attached a test demonstrating the problem. There are two DRL files, one which declares a fact entirely, and another which adds @Traitable to a POJO fact. The declared fact and the POJO fact have identical structure, and the rules are also otherwise identical. However, the declared test passes, while the POJO test fails. Is this a bug, or am I doing something horribly wrong? Thanks. Mike PojoFact.java Description: Binary data TraitTest.java Description: Binary data declared-fact-trait-test.drl Description: Binary data pojo-fact-trait-test.drl Description: Binary data ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Possible bug with isA operator
Davide,
Thanks very much for the prompt reply and detailed explanation. I do
have some control over my POJO facts (and most of them do already
implement equals/hashCode correctly), so I will experiment with your
presented alternative/workaround.
I am excited about traits because they allow me to rewrite some of my
more complex rules much more cleanly/clearly. I will certainly keep in
touch with any other feedback I have.
JBRULES-3321 created.
Mike
On Wed, Dec 28, 2011 at 1:22 PM, Davide Sottara dso...@gmail.com wrote:
Thanks Mike,
I have found and solved the problem, I'll commit the fix together with some
other improvements in the next few days. Can you open a JIRA for this?
The problem here is that, in order to be traited, objects need a few
additional internal structures, hence the reason for the @Traitable
annotation. With declared beans, these structures are added automatically to
the class generated on the fly. With legacy (pojo) beans, that is
impossible - by convention we are not touching legacy classes - so a wrapper
is generated internally instead.
When you applied the isA operator to a legacy object type, the operator
was looking for those additional structures. I have modified the operator to
go and look for the wrapper corresponding to an object, so calling isA on a
legacy bean WILL be possible, but discouraged.
Another option would be :
when
$p : PojoFact( ... )
[ not / exists ] Thing( core == $p )
then
All traits implement Thing, so this rule effectively looks for legacy
objects which have (not) been traited. You can use more specific types than
Thing if you want. With respect to isA, which probably will be renamed
hasType, this will also be triggered by more specific traits. Remember
that traits are interfaces, so inheritance is possible. The drawback here is
that your legacy bean must implement equals() ad hashCode() appropriately,
considering that an object might be compared not just with itself or objects
of the same class, but also with instances of proxy subclasses.
For example, in your case you should write something like:
@Override
public boolean equals(Object o) {
if (this == o) return true;
if ( ! ( o instanceof PojoFact ) ) return false;
PojoFact pojoFact = (PojoFact) o;
if ( getId() != pojoFact.getId() ) return false;
return true;
}
@Override
public int hashCode() {
return id;
}
Feel free to ask more questions and report more bugs and suggestions ;)
The code is very experimental and still work in progress, in time it will
come with better robustness and documentation
Best
Davide
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-Possible-bug-with-isA-operator-tp3616614p3616963.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Possible bug with isA operator
The drawback here is that your legacy bean must implement equals() ad hashCode() appropriately, considering that an object might be compared not just with itself or objects of the same class, but also with instances of proxy subclasses. Ah! I missed that important point. I had actually tried something similar to your alternative earlier, but it wasn't working. Now I understand why. I can update my equals/hashCode implementations so they will work with proxy subclasses. Excellent! Mike ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Possible bug with isA operator
Btw, if you agree I will include your submitted test cases in the trunk code Please do. Thanks. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] More temporal operator questions
If you'll indulge me, I have a couple more questions on temporal operators. I have specific requirements where the built-in operators don't *quite* fit. I'm finding workarounds but I don't love them and basically I'm looking for validation of my approach or better ideas. 1. I need an operator that means includes with endpoints. In other words, A includeswithendpoints B means A.start = B.start B.end = A.end. Another way to look at it is: A includes or coincides or starts or finishedby B. I've been messing around with the parameters to includes. Ideally, I'd represent this as includes[0, duration], where duration is A's duration. This would mean that the minimum distance between the start and end timestamps is 0 and the maximum distance between the start and end points is Event A's duration. However, I haven't been able to find a way to pass a dynamic parameter to the operator. My workaround in this case is includes[0, 100d], where 100d is just an arbitrarily large number. My tests so far have borne this out as working, but I don't like it because it's not very self-explanatory; everywhere I use it, I will need to include a comment. The beauty of the temporal operators is that they are intuitive and I feel like this workaround is compromising that. 2. Given an interval-based event A and a point-in-time event B, I need an operator which means A finishedby or includes B; i.e., A.start B.timestamp = A.end. Similarly, in this case, the workaround is includes[1ms, 100d, 0, 100d]. This takes the ugliness and need for explanatory comments to a new level. A few questions: 1. Is there any technical reason why my workarounds won't work (besides the obvious one where there is an event that lasts 101 days)? 2. Are there better solutions? (e.g., can I define my own operators?) 3. As a general rule, I avoid using or logic in my rules. However, is this a case where I should consider it? To me, EventA( this includes $eventB || this finishedby $eventB ) is much cleaner than EventA( this includes[1ms, 100d, 0, 100d] $eventB ), but that doesn't mean I like it. Thanks in advance for any feedback. Mike ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] More temporal operator questions
Concerning #3: There is no need to avoid a logical disjunction of two constraints within a single pattern. It's only a disjunction of patterns that results in a rule split, which may cause surprising results. Ah. That was a distinction I hadn't caught on to, though it's pretty obvious to me now that I think about it. I will just go that route then; it results in much more readable code. Thanks. Mike ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Temporal operators for point-in-time events
Apologies for the stupid question, but I haven't seen anything in the documentation regarding this and I want to verify my solution. Say I have a point-in-time event (i.e., duration of 0) that I want to correlate to another point-in-time event. I want a rule that will activate if the timestamp of one is greater than or equal to the other, basically after or coincides. I wrote a test using the following rule and it seemed to work: rule Greater Than or Equal when $e1 : TestEvent( $id : id ) $e2 : TestEvent( id != id, this after[0ms] $e1 ) then System.out.println($e2 + is greater than or equal to + $e1); end I realize this rule will fire twice if the event timestamps are equal, but it's just for demonstration purposes; my question is specifically about the after[0ms] part. Is this the way to go to accomplish what I need? It seems so simple but I have this annoying feeling that I'm missing something. On a slightly related topic, is there an updated version of the temporal operators image from the Drools Fusion homepage? It is a great visual description of the operators and I want to print it out and post it at my desk, but it doesn't include all of the operators. Image: http://www.jboss.org/drools/drools-fusion/mainColumnParagraphs/02/imageBinary/temporal-operators.png From page: http://www.jboss.org/drools/drools-fusion.html Thanks Mike ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Temporal operators for point-in-time events
Thank you, Edson. I saw the written documentation but since the default after interval is [1ms, infinity], I wanted to check for the specific [0, infinity] case that there wasn't a better suited operator. I do have a (somewhat related) question about the documentation when compared to the diagram(s). Take, for example, the finishedby operator. The documentation says A finishedby B means A starts before B and A and B finish at the same time. However, the diagram shows A starting *after* B and A and B finishing at the same time. The other related operators (finishes, starts, startedby) all have the same discrepancy. (Additionally, the second diagram in the presentation includes a different definition for the finishes operator than the first diagram. Maybe it should be startedby?) My tests show me that the written documentation is correct and the diagram is not. Unless I am reading the diagram incorrectly; if that is the case, can someone explain it? Thanks. 2011/12/13 Edson Tirelli ed.tire...@gmail.com: Your use of the after operator is correct. The documentation tells you about that, although in textual form: http://docs.jboss.org/drools/release/5.3.0.Final/drools-fusion-docs/html_single/index.html#d0e611 This presentation has the 2 tables of operators: http://www.slideshare.net/ge0ffrey/applying-cep-drools-fusion-drools-jbpm-bootcamps-2011 Edson On Tue, Dec 13, 2011 at 12:11 PM, Mike Melton mike.mel...@gmail.com wrote: Apologies for the stupid question, but I haven't seen anything in the documentation regarding this and I want to verify my solution. Say I have a point-in-time event (i.e., duration of 0) that I want to correlate to another point-in-time event. I want a rule that will activate if the timestamp of one is greater than or equal to the other, basically after or coincides. I wrote a test using the following rule and it seemed to work: rule Greater Than or Equal when $e1 : TestEvent( $id : id ) $e2 : TestEvent( id != id, this after[0ms] $e1 ) then System.out.println($e2 + is greater than or equal to + $e1); end I realize this rule will fire twice if the event timestamps are equal, but it's just for demonstration purposes; my question is specifically about the after[0ms] part. Is this the way to go to accomplish what I need? It seems so simple but I have this annoying feeling that I'm missing something. On a slightly related topic, is there an updated version of the temporal operators image from the Drools Fusion homepage? It is a great visual description of the operators and I want to print it out and post it at my desk, but it doesn't include all of the operators. Image: http://www.jboss.org/drools/drools-fusion/mainColumnParagraphs/02/imageBinary/temporal-operators.png From page: http://www.jboss.org/drools/drools-fusion.html Thanks Mike ___ 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 ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
