[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] 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" 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
>
>> 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 wrote:
>>
>>> 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 shoul
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
> 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 wrote:
>
>> 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
>>
>>> 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 consequenc
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
> 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] 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 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 List> 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 execute(Command 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
[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 List> 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 execute(Command 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 > 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
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
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
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 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
[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] 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] 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] 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 : > > 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 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
[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
