5:33 p.m.
Below is a test to demonstrate it, also add the @PropertyReactive property to
MyClass()
package com.sample;
rule base
when m : MyClass(data == null)
then
end
rule "2" extends base
when
String()
MyClass(value != "test") from m
then
System.out.println("2 fired");
end
rule "1" extends base
salience 1
when
MyClass(value == null) from m
then
System.out.println("1 fired");
insert(new String());
modify(m) { setValue("test") }
end
The test above should output "1 fired" and "2 fired".
Although we have set the value to "test", rule "2" supposes to not
fire, but
it is in fact expected to fire due to the non-reactive property of CE
"from", and the result confirms this.
But if we reorder the code in rule "1" to
rule "1" extends base
salience 1
when
MyClass(value == null) from m
then
System.out.println("1 fired");
modify(m) { setValue("test") }
insert(new String());
end
Then you get only "1 fired", as if CE "from" is reactive again.
This only happens when you have the @PropertyReactive property added to
MyClass()
Version tested are 5.5.0.Final and 5.6.0.Final
Could the Drools team review this? Thank you.
--
View this message in context:
http://drools.46999.n3.nabble.com/Inconsistent-output-when-PropertyReacti...
Sent from the Drools: User forum mailing list archive at Nabble.com.
5:49 p.m.
property reactive will not work with ‘from’.
Mark
On 15 Jan 2014, at 23:33, Sonata <plz.write.to(a)gmail.com> wrote:
Below is a test to demonstrate it, also add the @PropertyReactive
property to
MyClass()
package com.sample;
rule base
when m : MyClass(data == null)
then
end
rule "2" extends base
when
String()
MyClass(value != "test") from m
then
System.out.println("2 fired");
end
rule "1" extends base
salience 1
when
MyClass(value == null) from m
then
System.out.println("1 fired");
insert(new String());
modify(m) { setValue("test") }
end
The test above should output "1 fired" and "2 fired".
Although we have set the value to "test", rule "2" supposes to not
fire, but
it is in fact expected to fire due to the non-reactive property of CE
"from", and the result confirms this.
But if we reorder the code in rule "1" to
rule "1" extends base
salience 1
when
MyClass(value == null) from m
then
System.out.println("1 fired");
modify(m) { setValue("test") }
insert(new String());
end
Then you get only "1 fired", as if CE "from" is reactive again.
This only happens when you have the @PropertyReactive property added to
MyClass()
Version tested are 5.5.0.Final and 5.6.0.Final
Could the Drools team review this? Thank you.
--
View this message in context:
http://drools.46999.n3.nabble.com/Inconsistent-output-when-PropertyReacti...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:08 p.m.
Mark Proctor wrote
property reactive will not work with ‘from’.
Mark
Yes I am aware of that and I stated that on my post already.
But this "will not work with ‘from’" is not consistence, making the result
unpredictable.
--
View this message in context:
http://drools.46999.n3.nabble.com/Inconsistent-output-when-PropertyReacti...
Sent from the Drools: User forum mailing list archive at Nabble.com.
6:48 p.m.
ordering matters, it’s not inconsistent.
The from is applied in the alpha network, it stops reactive of pattern modify.
The insert joins with the ‘from’ in the beta network and propagates - @PR is not applied
at that level.
When ‘insert’ is first, there is nothing for it to join with; so the insert does nothing.
The later modify is ignored during @PR.
When the insert is after, while the @PR is ignored for the modify the insert will now join
with MyClass and propagate.
This is the expected behaviour.
Mark
On 16 Jan 2014, at 00:08, Sonata <plz.write.to(a)gmail.com> wrote:
Mark Proctor wrote
> property reactive will not work with ‘from’.
>
> Mark
Yes I am aware of that and I stated that on my post already.
But this "will not work with ‘from’" is not consistence, making the result
unpredictable.
--
View this message in context:
http://drools.46999.n3.nabble.com/Inconsistent-output-when-PropertyReacti...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:51 p.m.
Actually (and arguably) I think that the behavior is consistent.
In the first case, you insert a MyClass instance: base is eligible
for activation, and so is rule 1. When rule 1 fires, it inserts a String
which continues the previous propagation through rule 2. At this
point, value is still != "test" and an activation for rule 2 is created.
Now the modify: since the only @PR pattern is MyClass( data == null )
in rule "base" and you are setting the property value, the (re)propagation
is blocked. This prevents the previous activation of rule 2 from being
overwritten and cancelled, so rule 2 fires.
In the second example, things are slightly different. Rule 1 activates
as in the previous case, firing. This time, you modify m first, but since
no String is in the WM, there is nothing to (re)propagate or cancel
for rule 2. However, there is indeed a MyClass instance in the WM.
When you insert the String, the modification has already been
propagated: this time the String simply joins with the existing MyClass
and continues its propagation. The next node is a "from" which
checks the current value: it is now "test", so the alpha constraint
blocks the propagation. Rule 1 does not fire as expected, but
it has little do do with @PR.
Davide
On 01/16/2014 12:33 AM, Sonata wrote:
Below is a test to demonstrate it, also add the @PropertyReactive
property to
MyClass()
package com.sample;
rule base
when m : MyClass(data == null)
then
end
rule "2" extends base
when
String()
MyClass(value != "test") from m
then
System.out.println("2 fired");
end
rule "1" extends base
salience 1
when
MyClass(value == null) from m
then
System.out.println("1 fired");
insert(new String());
modify(m) { setValue("test") }
end
The test above should output "1 fired" and "2 fired".
Although we have set the value to "test", rule "2" supposes to not
fire, but
it is in fact expected to fire due to the non-reactive property of CE
"from", and the result confirms this.
But if we reorder the code in rule "1" to
rule "1" extends base
salience 1
when
MyClass(value == null) from m
then
System.out.println("1 fired");
modify(m) { setValue("test") }
insert(new String());
end
Then you get only "1 fired", as if CE "from" is reactive again.
This only happens when you have the @PropertyReactive property added to
MyClass()
Version tested are 5.5.0.Final and 5.6.0.Final
Could the Drools team review this? Thank you.
--
View this message in context:
http://drools.46999.n3.nabble.com/Inconsistent-output-when-PropertyReacti...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:51 p.m.
Thanks very much for the detailed explanation Mark Proctor and Davide
Sottara!
I really wouldn't have thought that the ordering of code matters here while
they are logically equivalent.
And to understand that is actually required to be at very low level...
So to sum up, when you have @PropertyReactive
1. "from" conditions are not re-evaluated
2. unless it has another non "from" condition preceding it and that
condition is re-evaluated (by insert or modify)
and this is expected behaviour.
--
View this message in context:
http://drools.46999.n3.nabble.com/Inconsistent-output-when-PropertyReacti...
Sent from the Drools: User forum mailing list archive at Nabble.com.
3973
days inactive
3974
days old
5 comments
3 participants
participants (3)
-
Davide Sottara -
Mark Proctor -
Sonata