8:24 a.m.
Hi all!
We have the problem that the following rule never fires:
rule "test-rule"
agenda-group "evaluation"
salience 100
when
$cue : AnalysisCue() from entry-point "LowLevelCueStream"
not(AnalysisCue(this after[0ms,2500ms] $cue) from entry-point
"LowLevelCueStream")
then
logger.debug("... some message ..");
end
We found out that the problem is the combination of the negation with the conditional
element "not" and the temporal constraint "[0ms,2500ms]". Using the
temporal operator "this after $cue" without a temporal constraint works correct
in its semantics.
Interestingly, when adding a constraint (cueType == 1) to the type in the negative pattern
the rule begins to work. The rule would look like as follows:
rule "test-rule"
agenda-group "evaluation"
salience 100
when
$cue : AnalysisCue() from entry-point "LowLevelCueStream"
not(AnalysisCue(cueType == 1, this after[0ms,2500ms] $cue) from entry-point
"LowLevelCueStream")
then
logger.debug("... some message ..");
end
unfortunately the rule then fires with a delay of 4 to 5 seconds. The second parameter of
the temporal constraint influences the delay.
When changing the first parameter of the temporal constraint to a value greater than 0 the
rule works as expected! The constraint would then look like as follows: "[1ms,
2500ms]". Whereas in our case, we want to evaluate the time window from 0 - 2500ms.
Our system works in the stream mode and we could reproduce this behaviour with the
versions 5.3.1 and 5.4.0 Beta 1.
Can anybody confirm if this is a bug in Drools, or did I overlook here something?
Best regards,
Wolfgang Weiss
8:57 a.m.
I don't see that the "not" CE excludes the AnalysisCue bound to $cue from
being
matched by the pattern inside the "not". I recommend using
* not*(AnalysisCue(*this != $cue*, this after[0ms,2500ms] $cue) from
since "[0ms,..." does not inhibit the same event being matched by both
patterns,
which precludes the rule from firing.
-W
2012/1/16 Weiss, Wolfgang <Wolfgang.Weiss(a)joanneum.at>
Hi all!****
** **
We have the problem that the following rule never fires:****
** **
*rule* "test-rule"****
*agenda-group* "evaluation"****
*salience* 100****
****
*when*****
$cue : AnalysisCue() *from* entry-point "LowLevelCueStream"**
**
*not*(AnalysisCue(*this* after[0ms,2500ms] $cue) *from*entry-point
"LowLevelCueStream")****
*then*****
logger.debug("... some message ..");****
*end*****
** **
We found out that the problem is the combination of the negation with the
conditional element “not” and the temporal constraint “[0ms,2500ms]”. Using
the temporal operator “this after $cue” without a temporal constraint works
correct in its semantics.****
Interestingly, when adding a constraint (cueType == 1) to the type in the
negative pattern the rule begins to work. The rule would look like as
follows:****
** **
*rule* "test-rule"****
*agenda-group* "evaluation"****
*salience* 100****
****
*when*****
$cue : AnalysisCue() *from* entry-point "LowLevelCueStream"**
**
*not*(AnalysisCue(cueType == 1, *this* after[0ms,2500ms]
$cue) *from* entry-point "LowLevelCueStream")****
*then*****
logger.debug("... some message ..");****
*end*****
** **
unfortunately the rule then fires with a delay of 4 to 5 seconds. The
second parameter of the temporal constraint influences the delay.****
When changing the first parameter of the temporal constraint to a value
greater than 0 the rule works as expected! The constraint would then look
like as follows: “[1ms, 2500ms]”. Whereas in our case, we want to evaluate
the time window from 0 – 2500ms.****
** **
Our system works in the stream mode and we could reproduce this behaviour
with the versions 5.3.1 and 5.4.0 Beta 1. ****
Can anybody confirm if this is a bug in Drools, or did I overlook here
something?****
** **
** **
Best regards,****
Wolfgang Weiss****
** **
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
2:27 a.m.
New subject: Problem with Negative Patterns and Temporal Constraints
Thank you for the quick answer! This makes absolutely sense and the rules work now as
expected.
Unfortunately, I was not able to find this somewhere in the documentation. It would be
nice to see it in the documentation of drools fusion.
Best,
Wolfgang
Von: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] Im
Auftrag von Wolfgang Laun
Gesendet: Montag, 16. Jänner 2012 15:58
An: Rules Users List
Betreff: Re: [rules-users] Problem with Negative Patterns and Temporal Constraints
I don't see that the "not" CE excludes the AnalysisCue bound to $cue from
being
matched by the pattern inside the "not". I recommend using
not(AnalysisCue(this != $cue, this after[0ms,2500ms] $cue) from
since "[0ms,..." does not inhibit the same event being matched by both
patterns,
which precludes the rule from firing.
-W
2012/1/16 Weiss, Wolfgang
<Wolfgang.Weiss@joanneum.at<mailto:Wolfgang.Weiss@joanneum.at>>
Hi all!
We have the problem that the following rule never fires:
rule "test-rule"
agenda-group "evaluation"
salience 100
when
$cue : AnalysisCue() from entry-point "LowLevelCueStream"
not(AnalysisCue(this after[0ms,2500ms] $cue) from entry-point
"LowLevelCueStream")
then
logger.debug("... some message ..");
end
We found out that the problem is the combination of the negation with the conditional
element "not" and the temporal constraint "[0ms,2500ms]". Using the
temporal operator "this after $cue" without a temporal constraint works correct
in its semantics.
Interestingly, when adding a constraint (cueType == 1) to the type in the negative pattern
the rule begins to work. The rule would look like as follows:
rule "test-rule"
agenda-group "evaluation"
salience 100
when
$cue : AnalysisCue() from entry-point "LowLevelCueStream"
not(AnalysisCue(cueType == 1, this after[0ms,2500ms] $cue) from entry-point
"LowLevelCueStream")
then
logger.debug("... some message ..");
end
unfortunately the rule then fires with a delay of 4 to 5 seconds. The second parameter of
the temporal constraint influences the delay.
When changing the first parameter of the temporal constraint to a value greater than 0 the
rule works as expected! The constraint would then look like as follows: "[1ms,
2500ms]". Whereas in our case, we want to evaluate the time window from 0 - 2500ms.
Our system works in the stream mode and we could reproduce this behaviour with the
versions 5.3.1 and 5.4.0 Beta 1.
Can anybody confirm if this is a bug in Drools, or did I overlook here something?
Best regards,
Wolfgang Weiss
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
3:27 a.m.
This is just following the basic principles of matching facts to patterns, e.g.
$p1: Person( $age: age )
$p2: Person( age >= $age )
binds (apart from many other results) each Person fact to both patterns.
The temporal operators are merely shortcuts for complex relations; do
not expect anything beyond that.
-W
On 17/01/2012, Weiss, Wolfgang <Wolfgang.Weiss(a)joanneum.at> wrote:
Thank you for the quick answer! This makes absolutely sense and the
rules
work now as expected.
Unfortunately, I was not able to find this somewhere in the documentation.
It would be nice to see it in the documentation of drools fusion.
Best,
Wolfgang
Von: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] Im Auftrag von Wolfgang Laun
Gesendet: Montag, 16. Jänner 2012 15:58
An: Rules Users List
Betreff: Re: [rules-users] Problem with Negative Patterns and Temporal
Constraints
I don't see that the "not" CE excludes the AnalysisCue bound to $cue from
being
matched by the pattern inside the "not". I recommend using
not(AnalysisCue(this != $cue, this after[0ms,2500ms] $cue) from
since "[0ms,..." does not inhibit the same event being matched by both
patterns,
which precludes the rule from firing.
-W
2012/1/16 Weiss, Wolfgang
<Wolfgang.Weiss@joanneum.at<mailto:Wolfgang.Weiss@joanneum.at>>
Hi all!
We have the problem that the following rule never fires:
rule "test-rule"
agenda-group "evaluation"
salience 100
when
$cue : AnalysisCue() from entry-point "LowLevelCueStream"
not(AnalysisCue(this after[0ms,2500ms] $cue) from entry-point
"LowLevelCueStream")
then
logger.debug("... some message ..");
end
We found out that the problem is the combination of the negation with the
conditional element "not" and the temporal constraint "[0ms,2500ms]".
Using
the temporal operator "this after $cue" without a temporal constraint works
correct in its semantics.
Interestingly, when adding a constraint (cueType == 1) to the type in the
negative pattern the rule begins to work. The rule would look like as
follows:
rule "test-rule"
agenda-group "evaluation"
salience 100
when
$cue : AnalysisCue() from entry-point "LowLevelCueStream"
not(AnalysisCue(cueType == 1, this after[0ms,2500ms] $cue) from
entry-point "LowLevelCueStream")
then
logger.debug("... some message ..");
end
unfortunately the rule then fires with a delay of 4 to 5 seconds. The second
parameter of the temporal constraint influences the delay.
When changing the first parameter of the temporal constraint to a value
greater than 0 the rule works as expected! The constraint would then look
like as follows: "[1ms, 2500ms]". Whereas in our case, we want to evaluate
the time window from 0 - 2500ms.
Our system works in the stream mode and we could reproduce this behaviour
with the versions 5.3.1 and 5.4.0 Beta 1.
Can anybody confirm if this is a bug in Drools, or did I overlook here
something?
Best regards,
Wolfgang Weiss
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
3:41 a.m.
On 17/01/2012 08:27, Weiss, Wolfgang wrote:
Thank you for the quick answer! This makes absolutely sense and the
rules work now as expected.
Unfortunately, I was not able to find this somewhere in the
documentation. It would be nice to see it in the documentation of
drools fusion.
Documentation is something anyone can do with a spare 10 minutes:
1) install git
2) install xmlmind
3) "fork" drools on github, https://github.com/droolsjbpm/drools
4) clone your fork locally
5) make changes to files with xmlmind, or xml editor of choice
https://github.com/droolsjbpm/drools/tree/master/drools-docs/drools-fusio...
6) commit changes, push changes back to github
7) use github gui to submit a pull request for your changes.
It'll be more obvious to users what documentation is missing, and
they'll be able to word it better in a way that makes more sense to
other users.
Mark
Best,
Wolfgang
*Von:*rules-users-bounces@lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] *Im Auftrag von *Wolfgang
Laun
*Gesendet:* Montag, 16. Jänner 2012 15:58
*An:* Rules Users List
*Betreff:* Re: [rules-users] Problem with Negative Patterns and
Temporal Constraints
I don't see that the "not" CE excludes the AnalysisCue bound to $cue
from being
matched by the pattern inside the "not". I recommend using
* not*(AnalysisCue(*this != $cue*, this after[0ms,2500ms] $cue) from
since "[0ms,..." does not inhibit the same event being matched by both
patterns,
which precludes the rule from firing.
-W
2012/1/16 Weiss, Wolfgang <Wolfgang.Weiss(a)joanneum.at
<mailto:Wolfgang.Weiss@joanneum.at>>
Hi all!
We have the problem that the following rule never fires:
*rule*"test-rule"
*agenda-group* "evaluation"
*salience* 100
*when*
$cue : AnalysisCue() *from* entry-point "LowLevelCueStream"
*not*(AnalysisCue(*this* after[0ms,2500ms] $cue) *from* entry-point
"LowLevelCueStream")
*then*
logger.debug("... some message ..");
*end*
We found out that the problem is the combination of the negation with
the conditional element "not" and the temporal constraint
"[0ms,2500ms]". Using the temporal operator "this after $cue" without
a temporal constraint works correct in its semantics.
Interestingly, when adding a constraint (cueType == 1) to the type in
the negative pattern the rule begins to work. The rule would look like
as follows:
*rule*"test-rule"
*agenda-group* "evaluation"
*salience* 100
*when*
$cue : AnalysisCue() *from* entry-point "LowLevelCueStream"
*not*(AnalysisCue(cueType == 1, *this* after[0ms,2500ms] $cue) *from*
entry-point "LowLevelCueStream")
*then*
logger.debug("... some message ..");
*end*
unfortunately the rule then fires with a delay of 4 to 5 seconds. The
second parameter of the temporal constraint influences the delay.
When changing the first parameter of the temporal constraint to a
value greater than 0 the rule works as expected! The constraint would
then look like as follows: "[1ms, 2500ms]". Whereas in our case, we
want to evaluate the time window from 0 -- 2500ms.
Our system works in the stream mode and we could reproduce this
behaviour with the versions 5.3.1 and 5.4.0 Beta 1.
Can anybody confirm if this is a bug in Drools, or did I overlook here
something?
Best regards,
Wolfgang Weiss
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4:09 a.m.
Op 17-01-12 10:41, Mark Proctor schreef:
On 17/01/2012 08:27, Weiss, Wolfgang wrote:
>
> Thank you for the quick answer! This makes absolutely sense and the
> rules work now as expected.
>
> Unfortunately, I was not able to find this somewhere in the
> documentation. It would be nice to see it in the documentation of
> drools fusion.
>
Documentation is something anyone can do with a spare 10 minutes:
1) install git
2) install xmlmind
3) "fork" drools on github, https://github.com/droolsjbpm/drools
4) clone your fork locally
5) make changes to files with xmlmind, or xml editor of choice
https://github.com/droolsjbpm/drools/tree/master/drools-docs/drools-fusio...
6) commit changes, push changes back to github
7) use github gui to submit a pull request for your changes.
It'll be more obvious to users what documentation is missing, and
they'll be able to word it better in a way that makes more sense to
other users.
If it's just a typo you want to fix, there's a very fast
method:
1) Go to github to the correct file, for example:
https://github.com/droolsjbpm/drools/blob/master/drools-docs/drools-fusio...
2) Click "Edit this file", edit it and save
3) We automatically get a pull request and can accept it easily.
The only thing that can take longer then a few seconds here is 1)
finding the file.
But maybe the pressgang-styles can be adjusted
to generate a link next to each section title to the docbook source file
on github.
Mark
>
> Best,
>
> Wolfgang
>
> *Von:*rules-users-bounces@lists.jboss.org
> [mailto:rules-users-bounces@lists.jboss.org] *Im Auftrag von
> *Wolfgang Laun
> *Gesendet:* Montag, 16. Jänner 2012 15:58
> *An:* Rules Users List
> *Betreff:* Re: [rules-users] Problem with Negative Patterns and
> Temporal Constraints
>
> I don't see that the "not" CE excludes the AnalysisCue bound to $cue
> from being
> matched by the pattern inside the "not". I recommend using
>
> * not*(AnalysisCue(*this != $cue*, this after[0ms,2500ms] $cue) from
>
> since "[0ms,..." does not inhibit the same event being matched by
> both patterns,
> which precludes the rule from firing.
>
> -W
>
> 2012/1/16 Weiss, Wolfgang <Wolfgang.Weiss(a)joanneum.at
> <mailto:Wolfgang.Weiss@joanneum.at>>
>
> Hi all!
>
> We have the problem that the following rule never fires:
>
> *rule*"test-rule"
>
> *agenda-group* "evaluation"
>
> *salience* 100
>
> *when*
>
> $cue : AnalysisCue() *from* entry-point "LowLevelCueStream"
>
> *not*(AnalysisCue(*this* after[0ms,2500ms] $cue) *from* entry-point
> "LowLevelCueStream")
>
> *then*
>
> logger.debug("... some message ..");
>
> *end*
>
> We found out that the problem is the combination of the negation with
> the conditional element "not" and the temporal constraint
> "[0ms,2500ms]". Using the temporal operator "this after $cue"
without
> a temporal constraint works correct in its semantics.
>
> Interestingly, when adding a constraint (cueType == 1) to the type in
> the negative pattern the rule begins to work. The rule would look
> like as follows:
>
> *rule*"test-rule"
>
> *agenda-group* "evaluation"
>
> *salience* 100
>
> *when*
>
> $cue : AnalysisCue() *from* entry-point "LowLevelCueStream"
>
> *not*(AnalysisCue(cueType == 1, *this* after[0ms,2500ms] $cue) *from*
> entry-point "LowLevelCueStream")
>
> *then*
>
> logger.debug("... some message ..");
>
> *end*
>
> unfortunately the rule then fires with a delay of 4 to 5 seconds. The
> second parameter of the temporal constraint influences the delay.
>
> When changing the first parameter of the temporal constraint to a
> value greater than 0 the rule works as expected! The constraint would
> then look like as follows: "[1ms, 2500ms]". Whereas in our case, we
> want to evaluate the time window from 0 -- 2500ms.
>
> Our system works in the stream mode and we could reproduce this
> behaviour with the versions 5.3.1 and 5.4.0 Beta 1.
>
> Can anybody confirm if this is a bug in Drools, or did I overlook
> here something?
>
> Best regards,
>
> Wolfgang Weiss
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
With kind regards,
Geoffrey De Smet
4697
days inactive
4698
days old
5 comments
4 participants
participants (4)
-
Geoffrey De Smet -
Mark Proctor -
Weiss, Wolfgang -
Wolfgang Laun