4:21 a.m.
I am trying to understand why care should be taken to use "from" and
"lock-on-active" together, as is described in "Section 4.8.3.8.
Conditional
Element from" of
http://downloads.jboss.com/drools/docs/5.1.1.34858.FINAL/drools-expert/ht...
the Drools Reference Document .
It says "the use of from returns a new fact for all intents and purposes
each time it is evaluated." Why is it true?
Below is the full related-text copied from the Drools Reference Document for
your reference:
=== BEGIN ===
You must take caution, however, when using from, especially in conjunction
with the lock-on-active rule attribute as it may produce unexpected results.
Consider the example provided earlier, but now slightly modified as follows:
rule "Assign people in North Carolina (NC) to sales region 1"
ruleflow-group "test"
lock-on-active true
when
$p : Person( )
$a : Address( state == "NC") from $p.address
then
modify ($p) {} #Assign person to sales region 1 in a modify block
end
rule "Apply a discount to people in the city of Raleigh"
ruleflow-group "test"
lock-on-active true
when
$p : Person( )
$a : Address( city == "Raleigh") from $p.address
then
modify ($p) {} #Apply discount to person in a modify block
end
In the above example, persons in Raleigh, NC should be assigned to sales
region 1 and receive a discount; i.e., you would expect both rules to
activate and fire. Instead you will find that only the second rule fires.
If you were to turn on the audit log, you would also see that when the
second rule fires, it deactivates the first rule. Since the rule attribute
lock-on-active prevents a rule from creating new activations when a set of
facts change, the first rule fails to reactivate. Though the set of facts
have not changed, the use of from returns a new fact for all intents and
purposes each time it is evaluated.
=== END ===
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Why-Using-from-Always...
Sent from the Drools - User mailing list archive at Nabble.com.
4:27 a.m.
In reality it doesn't return any fact, it returns each of the values currently in the
list held by the bound fact ($p).
Each time the rule is re-evaluated (due to $p changing) it re-iterates over the list again
(as it doesn't know if the list has changed or not). Drools effectively doesn't
know anything about the $a's returned from the list nor does it keep track of them.
Hence when re-evaluating the rule it can't know if it is the same set of values that
matches last time or a different set of values.
Thomas
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-
bounces(a)lists.jboss.org] On Behalf Of hyjshanghai
Sent: 19 January 2011 10:21
To: rules-users(a)lists.jboss.org
Subject: [rules-users] Why Using "from" Always Return A New Fact?
I am trying to understand why care should be taken to use "from" and
"lock-on-active" together, as is described in "Section 4.8.3.8.
Conditional
Element from" of
http://downloads.jboss.com/drools/docs/5.1.1.34858.FINAL/drools-
expert/html/ch04.html
the Drools Reference Document .
It says "the use of from returns a new fact for all intents and purposes
each time it is evaluated." Why is it true?
Below is the full related-text copied from the Drools Reference Document for
your reference:
=== BEGIN ===
You must take caution, however, when using from, especially in conjunction
with the lock-on-active rule attribute as it may produce unexpected results.
Consider the example provided earlier, but now slightly modified as follows:
rule "Assign people in North Carolina (NC) to sales region 1"
ruleflow-group "test"
lock-on-active true
when
$p : Person( )
$a : Address( state == "NC") from $p.address
then
modify ($p) {} #Assign person to sales region 1 in a modify block
end
rule "Apply a discount to people in the city of Raleigh"
ruleflow-group "test"
lock-on-active true
when
$p : Person( )
$a : Address( city == "Raleigh") from $p.address
then
modify ($p) {} #Apply discount to person in a modify block
end
In the above example, persons in Raleigh, NC should be assigned to sales
region 1 and receive a discount; i.e., you would expect both rules to
activate and fire. Instead you will find that only the second rule fires.
If you were to turn on the audit log, you would also see that when the
second rule fires, it deactivates the first rule. Since the rule attribute
lock-on-active prevents a rule from creating new activations when a set of
facts change, the first rule fails to reactivate. Though the set of facts
have not changed, the use of from returns a new fact for all intents and
purposes each time it is evaluated.
=== END ===
--
View this message in context: http://drools-java-rules-
engine.46999.n3.nabble.com/Why-Using-from-Always-Return-A-New-Fact-
tp2286393p2286393.html
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the postmaster(a)nds.com and delete it from
your system as well as any copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the environment please
do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
4:40 a.m.
Thank you. I understand it now:
In the 2nd rule:
modify($p) => evaluate the 2nd rule again => re-iterate $p.address with
"from", so that Drools engine can know if there is any change in $p.address
compared with previous evaluation.
Also, the above modify($p) also triggers evaluation of the 1st rule.
Then, why "when the second rule fires, it deactivates the first rule." as
the document says?
I think nobody modifies $p.address.state. So the existing activation for the
1st rule should still hold. Why the 1st rule is not fired?
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Why-Using-from-Always...
Sent from the Drools - User mailing list archive at Nabble.com.
4:49 a.m.
Drools doesn't know if $p.address.state has changed or not, all it knows is that $p
has changed - it has to assume that everything within $p has changed (including all the
states).
Thomas
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-
bounces(a)lists.jboss.org] On Behalf Of hyjshanghai
Sent: 19 January 2011 10:40
To: rules-users(a)lists.jboss.org
Subject: Re: [rules-users] Why Using "from" Always Return A New Fact?
Thank you. I understand it now:
In the 2nd rule:
modify($p) => evaluate the 2nd rule again => re-iterate $p.address with
"from", so that Drools engine can know if there is any change in $p.address
compared with previous evaluation.
Also, the above modify($p) also triggers evaluation of the 1st rule.
Then, why "when the second rule fires, it deactivates the first rule." as
the document says?
I think nobody modifies $p.address.state. So the existing activation for the
1st rule should still hold. Why the 1st rule is not fired?
--
View this message in context: http://drools-java-rules-
engine.46999.n3.nabble.com/Why-Using-from-Always-Return-A-New-Fact-
tp2286393p2286492.html
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
**************************************************************************************
This message is confidential and intended only for the addressee. If you have received
this message in error, please immediately notify the postmaster(a)nds.com and delete it from
your system as well as any copies. The content of e-mails as well as traffic data may be
monitored by NDS for employment and security purposes. To protect the environment please
do not print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United
Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603
8808 40-00
**************************************************************************************
8:07 p.m.
You explanation is very reasonable:
the engine assumes anything within $p may be changed by modify($p), although
$p.address is not changed actually.
However, I tried these rules myself and both rules were fired. Why?
According to the document, only one of the rules should fire; the other's
activation should be cancelled because the engine assumes $p has changed,
which may mismatch the other rule, right?.
The following are the output and my rules. The only difference between my
rules and the document's is that my rules don't belong to any
ruleflow-group.
==== Program Output of Inserting a "new Person()" and Firing All Rules.
BEGIN====
Rule 'Apply discount' fired. Person: Person{name[Tom],
address[Address{state[NC], city[Raleigh]}], region[null], discount[0.9]}
Rule 'Assign to sales region 1' fired. Person: Person{name[Tom],
address[Address{state[NC], city[Raleigh]}], region[sales region 1],
discount[0.9]}
==== Program Output of Inserting a "new Person()" and Firing All Rules.
END====
==== The Rules I Tested. BEGIN ====
package hello.rules
import java.util.*
import java.math.*
import hello.model.Address;
import hello.model.Person;
rule "Assign to sales region 1"
lock-on-active true
when
$p : Person()
$a : Address( state=="NC") from $p.address
then
modify ($p) { setRegion("sales region 1") }
System.out.println("Rule 'Assign to sales region 1' fired. Person:
"+$p);
end
rule "Apply discount"
lock-on-active true
when
$p : Person()
$a : Address( city=="Raleigh") from $p.address
then
modify ($p) { setDiscount((float)0.9) }
System.out.println("Rule 'Apply discount' fired. Person: "+$p);
end
==== The Rules I Tested. END ====
==== The Person and Address. BEGIN ====
public class Person
{
private String name;
private Address address;
private String region;
private float discount;
public String getRegion() {
return region;
}
public void setRegion(String region) {
this.region = region;
}
public float getDiscount() {
return discount;
}
public void setDiscount(float discount) {
this.discount = discount;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Address getAddress() {
return address;
}
public void setAddress(Address address) {
this.address = address;
}
@Override
public String toString()
{
return String.format("Person{name[%s], address[%s], region[%s],
discount[%s]}",
name, address.toString(), region, discount);
}
}
public class Address
{
private String state;
private String city;
public String getState() {
return state;
}
public void setState(String state) {
this.state = state;
}
public String getCity() {
return city;
}
public void setCity(String city) {
this.city = city;
}
@Override
public String toString()
{
return String.format("Address{state[%s], city[%s]}", state, city);
}
}
==== The Person and Address END ====
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Why-Using-from-Always...
Sent from the Drools - User mailing list archive at Nabble.com.
10:04 p.m.
As of Drools 5.1.1, drools looks at the expression in "from" as a
black box. Every time it is executed, drools creates a new fact handle
to wrap the result(s). Since the lock and no-loop features are based
on the fact handles, the sometimes undesired interaction occurs. We
may be able to improve this in drools 6, when we will have the engine
owning 100% of the language syntax, that will enable us to run better
expression analisys than we can do today.
Edson
Em quarta-feira, 19 de janeiro de 2011,
hyjshanghai<hyjshanghai(a)gmail.com> escreveu:
You explanation is very reasonable:
the engine assumes anything within $p may be changed by modify($p), although
$p.address is not changed actually.
However, I tried these rules myself and both rules were fired. Why?
According to the document, only one of the rules should fire; the other's
activation should be cancelled because the engine assumes $p has changed,
which may mismatch the other rule, right?.
The following are the output and my rules. The only difference between my
rules and the document's is that my rules don't belong to any
ruleflow-group.
==== Program Output of Inserting a "new Person()" and Firing All Rules.
BEGIN====
Rule 'Apply discount' fired. Person: Person{name[Tom],
address[Address{state[NC], city[Raleigh]}], region[null], discount[0.9]}
Rule 'Assign to sales region 1' fired. Person: Person{name[Tom],
address[Address{state[NC], city[Raleigh]}], region[sales region 1],
discount[0.9]}
==== Program Output of Inserting a "new Person()" and Firing All Rules.
END====
==== The Rules I Tested. BEGIN ====
package hello.rules
import java.util.*
import java.math.*
import hello.model.Address;
import hello.model.Person;
rule "Assign to sales region 1"
lock-on-active true
when
$p : Person()
$a : Address( state=="NC") from $p.address
then
modify ($p) { setRegion("sales region 1") }
System.out.println("Rule 'Assign to sales region 1' fired. Person:
"+$p);
end
rule "Apply discount"
lock-on-active true
when
$p : Person()
$a : Address( city=="Raleigh") from $p.address
then
modify ($p) { setDiscount((float)0.9) }
System.out.println("Rule 'Apply discount' fired. Person: "+$p);
end
==== The Rules I Tested. END ====
==== The Person and Address. BEGIN ====
public class Person
{
private String name;
private Address address;
private String region;
private float discount;
public String getRegion() {
return region;
}
public void setRegion(String region) {
this.region = region;
}
public float getDiscount() {
return discount;
}
public void setDiscount(float discount) {
this.discount = discount;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Address getAddress() {
return address;
}
public void setAddress(Address address) {
this.address = address;
}
@Override
public String toString()
{
return String.format("Person{name[%s], address[%s], region[%s],
discount[%s]}",
name, address.toString(), region, discount);
}
}
public class Address
{
private String state;
private String city;
public String getState() {
return state;
}
public void setState(String state) {
this.state = state;
}
public String getCity() {
return city;
}
public void setCity(String city) {
this.city = city;
}
@Override
public String toString()
{
return String.format("Address{state[%s], city[%s]}", state, city);
}
}
==== The Person and Address END ====
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Why-Using-from-Always...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
11:40 p.m.
OK. You mean the behavior differs by versions. My above test in which both
rules fired was using Drools 5.1.1.
Questions:
1. "Since the lock and no-loop features are based on the fact handles, the
sometimes undesired interaction occurs."
Could you elaborate more on how is lock-on-active based on fact handles?
2. Is it the expected design that when I ran my above rules in Drools 5.1.1
both rules should fire? How is it related to the fact that lock-on-active is
based on fact handles?
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Why-Using-from-Always...
Sent from the Drools - User mailing list archive at Nabble.com.
10:47 a.m.
Yes, it might be different from version to version as we improve the
overall algorithm. The reason for the different behavior is that under
Drools 5.0 (and in most rule engines out there), every modify is just a
retract+assert. So, the different fact handles would prevent the proper
normalization of the activations. 5.1.x improved the algorithm with what we
call true modify, where a modify is a real modify (not retract+assert). This
algorithm allowed me to implement an optimization based on the system ID of
the objects returned by the from expression: if it is the same identity of a
previously existing fact, it will not recreate the fact handle, but reuse
the existing one. That means the first rule was not cancelled and
reactivated, it just remained active and so the from didn't had a direct
effect on the lock-on-modify. There are scenarios, though where this still
might happen, but I would have to review all that. The general advice as of
now is still to avoid using "from" with "lock-on-active", but I expect
that
restriction to be lifted in drools 6.
Edson
2011/1/20 hyjshanghai <hyjshanghai(a)gmail.com>
OK. You mean the behavior differs by versions. My above test in which both
rules fired was using Drools 5.1.1.
Questions:
1. "Since the lock and no-loop features are based on the fact handles, the
sometimes undesired interaction occurs."
Could you elaborate more on how is lock-on-active based on fact handles?
2. Is it the expected design that when I ran my above rules in Drools 5.1.1
both rules should fire? How is it related to the fact that lock-on-active
is
based on fact handles?
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Why-Using-from-Always...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
3:54 a.m.
"The general advice as of now is still to avoid using "from" with
"lock-on-active", but I expect that restriction to be lifted in drools 6."
- I think this is the ultimate advice, we, as users, should take.
Thank you for so much explanation on the internal. I will ask more on the
internal if time permits in the future.
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Why-Using-from-Always...
Sent from the Drools - User mailing list archive at Nabble.com.
10:28 a.m.
When you say "owning 100% of the language syntax" does that include the RHS?
Just curious.
GreG
On Jan 19, 2011, at 22:04, Edson Tirelli <ed.tirelli(a)gmail.com> wrote:
As of Drools 5.1.1, drools looks at the expression in
"from" as a
black box. Every time it is executed, drools creates a new fact handle
to wrap the result(s). Since the lock and no-loop features are based
on the fact handles, the sometimes undesired interaction occurs. We
may be able to improve this in drools 6, when we will have the engine
owning 100% of the language syntax, that will enable us to run better
expression analisys than we can do today.
Edson
Em quarta-feira, 19 de janeiro de 2011,
hyjshanghai<hyjshanghai(a)gmail.com> escreveu:
>
> You explanation is very reasonable:
> the engine assumes anything within $p may be changed by modify($p), although
> $p.address is not changed actually.
>
> However, I tried these rules myself and both rules were fired. Why?
> According to the document, only one of the rules should fire; the other's
> activation should be cancelled because the engine assumes $p has changed,
> which may mismatch the other rule, right?.
>
> The following are the output and my rules. The only difference between my
> rules and the document's is that my rules don't belong to any
> ruleflow-group.
>
> ==== Program Output of Inserting a "new Person()" and Firing All Rules.
> BEGIN====
> Rule 'Apply discount' fired. Person: Person{name[Tom],
> address[Address{state[NC], city[Raleigh]}], region[null], discount[0.9]}
> Rule 'Assign to sales region 1' fired. Person: Person{name[Tom],
> address[Address{state[NC], city[Raleigh]}], region[sales region 1],
> discount[0.9]}
> ==== Program Output of Inserting a "new Person()" and Firing All Rules.
> END====
>
> ==== The Rules I Tested. BEGIN ====
> package hello.rules
> import java.util.*
> import java.math.*
> import hello.model.Address;
> import hello.model.Person;
>
> rule "Assign to sales region 1"
> lock-on-active true
> when
> $p : Person()
> $a : Address( state=="NC") from $p.address
> then
> modify ($p) { setRegion("sales region 1") }
> System.out.println("Rule 'Assign to sales region 1' fired. Person:
> "+$p);
> end
>
> rule "Apply discount"
> lock-on-active true
> when
> $p : Person()
> $a : Address( city=="Raleigh") from $p.address
> then
> modify ($p) { setDiscount((float)0.9) }
> System.out.println("Rule 'Apply discount' fired. Person: "+$p);
> end
> ==== The Rules I Tested. END ====
>
> ==== The Person and Address. BEGIN ====
> public class Person
> {
> private String name;
> private Address address;
> private String region;
> private float discount;
> public String getRegion() {
> return region;
> }
> public void setRegion(String region) {
> this.region = region;
> }
> public float getDiscount() {
> return discount;
> }
> public void setDiscount(float discount) {
> this.discount = discount;
> }
>
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
> public Address getAddress() {
> return address;
> }
> public void setAddress(Address address) {
> this.address = address;
> }
> @Override
> public String toString()
> {
> return String.format("Person{name[%s], address[%s], region[%s],
> discount[%s]}",
> name, address.toString(), region, discount);
> }
> }
>
> public class Address
> {
> private String state;
> private String city;
> public String getState() {
> return state;
> }
> public void setState(String state) {
> this.state = state;
> }
> public String getCity() {
> return city;
> }
> public void setCity(String city) {
> this.city = city;
> }
>
> @Override
> public String toString()
> {
> return String.format("Address{state[%s], city[%s]}", state, city);
> }
> }
> ==== The Person and Address END ====
> --
> View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Why-Using-from-Always...
> Sent from the Drools - User mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
10:57 a.m.
Yes, but just to clarify: as it is now, we parse semantic blocks of code
like RHS as a black box (chunk if you will) and then re-parse that with the
appropriate dialect parser (like java). Same for expressions in the rule,
that we chunk and delegate to MVEL. That is why, for instance, to write an
expression in a pattern in need the ugly ( ):
Person( age == ( $someAge + 1 ) )
That also screws with our error handling capabilities. Example: as of
today, in the eclipse editor, if you have a parsing error in the
consequence, we show the error in the rule header instead of the proper line
in the consequence.
The changes we are doing in the parser now means that we will be able to
parse 100% of the content of the DRL file (no black boxes/chunking anymore)
and with that improve error handling, code completion, improve syntax and
allow us to do smarter static code analysis. Example of the results as of
this morning:
@name4( k1 = "a",
formula = Math.max( 10 + 25, 22 ) % 2 + someVariable,
array = { a, b, c } )
Above example is for annotations, but the same will happen everywhere,
including the LHS. See how "formula" uses a free form expression without any
kind of clutter/delimiters/etc?
Edson
2011/1/20 Greg Barton <greg_barton(a)yahoo.com>
When you say "owning 100% of the language syntax" does that
include the
RHS? Just curious.
GreG
On Jan 19, 2011, at 22:04, Edson Tirelli <ed.tirelli(a)gmail.com> wrote:
> As of Drools 5.1.1, drools looks at the expression in "from" as a
> black box. Every time it is executed, drools creates a new fact handle
> to wrap the result(s). Since the lock and no-loop features are based
> on the fact handles, the sometimes undesired interaction occurs. We
> may be able to improve this in drools 6, when we will have the engine
> owning 100% of the language syntax, that will enable us to run better
> expression analisys than we can do today.
>
> Edson
>
> Em quarta-feira, 19 de janeiro de 2011,
> hyjshanghai<hyjshanghai(a)gmail.com> escreveu:
>>
>> You explanation is very reasonable:
>> the engine assumes anything within $p may be changed by modify($p),
although
>> $p.address is not changed actually.
>>
>> However, I tried these rules myself and both rules were fired. Why?
>> According to the document, only one of the rules should fire; the
other's
>> activation should be cancelled because the engine assumes $p has
changed,
>> which may mismatch the other rule, right?.
>>
>> The following are the output and my rules. The only difference between
my
>> rules and the document's is that my rules don't belong to any
>> ruleflow-group.
>>
>> ==== Program Output of Inserting a "new Person()" and Firing All
Rules.
>> BEGIN====
>> Rule 'Apply discount' fired. Person: Person{name[Tom],
>> address[Address{state[NC], city[Raleigh]}], region[null], discount[0.9]}
>> Rule 'Assign to sales region 1' fired. Person: Person{name[Tom],
>> address[Address{state[NC], city[Raleigh]}], region[sales region 1],
>> discount[0.9]}
>> ==== Program Output of Inserting a "new Person()" and Firing All
Rules.
>> END====
>>
>> ==== The Rules I Tested. BEGIN ====
>> package hello.rules
>> import java.util.*
>> import java.math.*
>> import hello.model.Address;
>> import hello.model.Person;
>>
>> rule "Assign to sales region 1"
>> lock-on-active true
>> when
>> $p : Person()
>> $a : Address( state=="NC") from $p.address
>> then
>> modify ($p) { setRegion("sales region 1") }
>> System.out.println("Rule 'Assign to sales region 1' fired.
Person:
>> "+$p);
>> end
>>
>> rule "Apply discount"
>> lock-on-active true
>> when
>> $p : Person()
>> $a : Address( city=="Raleigh") from $p.address
>> then
>> modify ($p) { setDiscount((float)0.9) }
>> System.out.println("Rule 'Apply discount' fired. Person:
"+$p);
>> end
>> ==== The Rules I Tested. END ====
>>
>> ==== The Person and Address. BEGIN ====
>> public class Person
>> {
>> private String name;
>> private Address address;
>> private String region;
>> private float discount;
>> public String getRegion() {
>> return region;
>> }
>> public void setRegion(String region) {
>> this.region = region;
>> }
>> public float getDiscount() {
>> return discount;
>> }
>> public void setDiscount(float discount) {
>> this.discount = discount;
>> }
>>
>> public String getName() {
>> return name;
>> }
>> public void setName(String name) {
>> this.name = name;
>> }
>> public Address getAddress() {
>> return address;
>> }
>> public void setAddress(Address address) {
>> this.address = address;
>> }
>> @Override
>> public String toString()
>> {
>> return String.format("Person{name[%s], address[%s], region[%s],
>> discount[%s]}",
>> name, address.toString(), region, discount);
>> }
>> }
>>
>> public class Address
>> {
>> private String state;
>> private String city;
>> public String getState() {
>> return state;
>> }
>> public void setState(String state) {
>> this.state = state;
>> }
>> public String getCity() {
>> return city;
>> }
>> public void setCity(String city) {
>> this.city = city;
>> }
>>
>> @Override
>> public String toString()
>> {
>> return String.format("Address{state[%s], city[%s]}", state,
city);
>> }
>> }
>> ==== The Person and Address END ====
>> --
>> View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Why-Using-from-Always...
>> Sent from the Drools - User mailing list archive at Nabble.com.
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
> --
> Edson Tirelli
> JBoss Drools Core Development
> JBoss by Red Hat @ www.jboss.com
>
> _______________________________________________
> 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
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
2:59 p.m.
On 20/01/2011 16:28, Greg Barton wrote:
When you say "owning 100% of the language syntax" does that
include the RHS? Just curious.
yes.
Mark
GreG
On Jan 19, 2011, at 22:04, Edson Tirelli<ed.tirelli(a)gmail.com> wrote:
> As of Drools 5.1.1, drools looks at the expression in "from" as a
> black box. Every time it is executed, drools creates a new fact handle
> to wrap the result(s). Since the lock and no-loop features are based
> on the fact handles, the sometimes undesired interaction occurs. We
> may be able to improve this in drools 6, when we will have the engine
> owning 100% of the language syntax, that will enable us to run better
> expression analisys than we can do today.
>
> Edson
>
> Em quarta-feira, 19 de janeiro de 2011,
> hyjshanghai<hyjshanghai(a)gmail.com> escreveu:
>> You explanation is very reasonable:
>> the engine assumes anything within $p may be changed by modify($p), although
>> $p.address is not changed actually.
>>
>> However, I tried these rules myself and both rules were fired. Why?
>> According to the document, only one of the rules should fire; the other's
>> activation should be cancelled because the engine assumes $p has changed,
>> which may mismatch the other rule, right?.
>>
>> The following are the output and my rules. The only difference between my
>> rules and the document's is that my rules don't belong to any
>> ruleflow-group.
>>
>> ==== Program Output of Inserting a "new Person()" and Firing All
Rules.
>> BEGIN====
>> Rule 'Apply discount' fired. Person: Person{name[Tom],
>> address[Address{state[NC], city[Raleigh]}], region[null], discount[0.9]}
>> Rule 'Assign to sales region 1' fired. Person: Person{name[Tom],
>> address[Address{state[NC], city[Raleigh]}], region[sales region 1],
>> discount[0.9]}
>> ==== Program Output of Inserting a "new Person()" and Firing All
Rules.
>> END====
>>
>> ==== The Rules I Tested. BEGIN ====
>> package hello.rules
>> import java.util.*
>> import java.math.*
>> import hello.model.Address;
>> import hello.model.Person;
>>
>> rule "Assign to sales region 1"
>> lock-on-active true
>> when
>> $p : Person()
>> $a : Address( state=="NC") from $p.address
>> then
>> modify ($p) { setRegion("sales region 1") }
>> System.out.println("Rule 'Assign to sales region 1' fired.
Person:
>> "+$p);
>> end
>>
>> rule "Apply discount"
>> lock-on-active true
>> when
>> $p : Person()
>> $a : Address( city=="Raleigh") from $p.address
>> then
>> modify ($p) { setDiscount((float)0.9) }
>> System.out.println("Rule 'Apply discount' fired. Person:
"+$p);
>> end
>> ==== The Rules I Tested. END ====
>>
>> ==== The Person and Address. BEGIN ====
>> public class Person
>> {
>> private String name;
>> private Address address;
>> private String region;
>> private float discount;
>> public String getRegion() {
>> return region;
>> }
>> public void setRegion(String region) {
>> this.region = region;
>> }
>> public float getDiscount() {
>> return discount;
>> }
>> public void setDiscount(float discount) {
>> this.discount = discount;
>> }
>>
>> public String getName() {
>> return name;
>> }
>> public void setName(String name) {
>> this.name = name;
>> }
>> public Address getAddress() {
>> return address;
>> }
>> public void setAddress(Address address) {
>> this.address = address;
>> }
>> @Override
>> public String toString()
>> {
>> return String.format("Person{name[%s], address[%s], region[%s],
>> discount[%s]}",
>> name, address.toString(), region, discount);
>> }
>> }
>>
>> public class Address
>> {
>> private String state;
>> private String city;
>> public String getState() {
>> return state;
>> }
>> public void setState(String state) {
>> this.state = state;
>> }
>> public String getCity() {
>> return city;
>> }
>> public void setCity(String city) {
>> this.city = city;
>> }
>>
>> @Override
>> public String toString()
>> {
>> return String.format("Address{state[%s], city[%s]}", state,
city);
>> }
>> }
>> ==== The Person and Address END ====
>> --
>> View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Why-Using-from-Always...
>> Sent from the Drools - User mailing list archive at Nabble.com.
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
> --
> Edson Tirelli
> JBoss Drools Core Development
> JBoss by Red Hat @ www.jboss.com
>
> _______________________________________________
> 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
5142
days inactive
5144
days old
11 comments
5 participants
participants (5)
-
Edson Tirelli -
Greg Barton -
hyjshanghai -
Mark Proctor -
Swindells, Thomas