9:02 a.m.
In getting our business rules written, we used a lot of domain experts to
help write our rules. I now have the exciting job of verifying and fixing
these rules as needed. When possible, I had asked that they use OR
statements in a single rule, as opposed to breaking them out into multiple
rules for brefity and ease of maintenance.
However, in trying to get these rules to function, I find myself time and
time again having to break OR logic into multiple rules to get it to work
(the || internal to objects seems to work okay). I have tried both prefix
and infix OR. Is there some limit to the complexity of when OR will or will
not work? I have tried using parenthesis to make the logic very explicit,
but often breaking it into multiple rules seems to be the only remedy.
Is there some principle to go by, or is this a matter of trial and error
when rules must be broken into multiple rules in the DRL? My understanding
was that the OR CE basically would be broken into multiple rules
automagically, which is what I end up doing manually in the DRL. Have you
heard of any problems with this functionality?
--
View this message in context:
http://www.nabble.com/Arbitrary-problem-using-OR--tf4481210.html#a12778131
Sent from the drools - user mailing list archive at Nabble.com.
9:48 a.m.
If you are using version 4.0.1, there should be no limit in the
complexity of the condition, using any of the available CEs. And your
understanding is correct when you say the engine automagically breaks the
rules into multiple subrules when you use OR CE.
As we speak, there is no known problem in the use of this functionality
in 4.0.1.
Can you please provide an example of the problems you are finding?
Thanks,
Edson
2007/9/19, wasabifan <bryan.rickman(a)kewill.com>:
In getting our business rules written, we used a lot of domain experts to
help write our rules. I now have the exciting job of verifying and fixing
these rules as needed. When possible, I had asked that they use OR
statements in a single rule, as opposed to breaking them out into multiple
rules for brefity and ease of maintenance.
However, in trying to get these rules to function, I find myself time and
time again having to break OR logic into multiple rules to get it to work
(the || internal to objects seems to work okay). I have tried both prefix
and infix OR. Is there some limit to the complexity of when OR will or
will
not work? I have tried using parenthesis to make the logic very explicit,
but often breaking it into multiple rules seems to be the only remedy.
Is there some principle to go by, or is this a matter of trial and error
when rules must be broken into multiple rules in the DRL? My
understanding
was that the OR CE basically would be broken into multiple rules
automagically, which is what I end up doing manually in the DRL. Have you
heard of any problems with this functionality?
--
View this message in context:
http://www.nabble.com/Arbitrary-problem-using-OR--tf4481210.html#a12778131
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
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
10:27 a.m.
Sure. Here is one example (though I think it may have an
existential/universal not error as mentioned in another post):
rule "6040 Pass CA Fees"
when
#conditions
$status : ValidationPassFailStatus()
exists ValidationControl(validationNo == 6040)
CiLines($ciNo : ciNo, $ciLineNo : ciLineNo, $countryOrigin :
countryOrigin)
Country(country == $countryOrigin, canadianProvince != "",
canadianProvince != "N")
(CiLineFees(amtFee == 0, ciNo == $ciNo, ciLineNo == $ciLineNo)
or not CiLineFees(ciNo == $ciNo, ciLineNo == $ciLineNo))
then
#actions
System.out.println("6040 Pass CA Fees");
$status.passSq(6040);
end
I have tried this with and without the parenthesis for explicitness. It
errors out when inserting facts for the rule:
java.lang.ClassCastException:
com.kewill.icustoms.customs.rules.model.ValidationPassFailStatusShadowProxy
at
org.drools.base.com.kewill.icustoms.dbi.model.CiLines$getCountryOrigin.getValue(Unknown
Source)
at
org.drools.base.extractors.BaseObjectClassFieldExtractor.getHashCode(BaseObjectClassFieldExtractor.java:139)
at
org.drools.base.ClassFieldExtractor.getHashCode(ClassFieldExtractor.java:173)
at org.drools.rule.Declaration.getHashCode(Declaration.java:272)
at
org.drools.util.AbstractHashTable$SingleIndex.hashCodeOf(AbstractHashTable.java:489)
at
org.drools.util.TupleIndexHashTable.getOrCreate(TupleIndexHashTable.java:280)
at org.drools.util.TupleIndexHashTable.add(TupleIndexHashTable.java:192)
at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:111)
...
However, if I break this into two separate rules, it behaves as expected
(with the possible existensial/universal logic problem I mention above).
rule "6040 Pass CA Fees"
when
#conditions
$status : ValidationPassFailStatus()
exists ValidationControl(validationNo == 6040)
CiLines($ciNo : ciNo, $ciLineNo : ciLineNo, $countryOrigin :
countryOrigin)
Country(country == $countryOrigin, canadianProvince != "",
canadianProvince != "N")
CiLineFees(amtFee == 0, ciNo == $ciNo, ciLineNo == $ciLineNo)
then
#actions
System.out.println("6040 Pass CA Fees");
$status.passSq(6040);
end
rule "6040 Pass CA No Fees"
when
#conditions
$status : ValidationPassFailStatus()
exists ValidationControl(validationNo == 6040)
CiLines($ciNo : ciNo, $ciLineNo : ciLineNo, $countryOrigin :
countryOrigin)
Country(country == $countryOrigin, canadianProvince != "",
canadianProvince != "N")
not CiLineFees(ciNo == $ciNo, ciLineNo == $ciLineNo)
then
#actions
System.out.println("6040 Pass CA No Fees");
$status.passSq(6040);
end
Edson Tirelli-3 wrote:
As we speak, there is no known problem in the use of this functionality
in 4.0.1.
Can you please provide an example of the problems you are finding?
Thanks,
Edson
--
View this message in context:
http://www.nabble.com/Arbitrary-problem-using-OR--tf4481210.html#a12779845
Sent from the drools - user mailing list archive at Nabble.com.
12:18 p.m.
Bryan,
This is a bug. May I ask you please to open a JIRA for it. I will fix and
include it into the 4.0.2 release.
Thanks,
Edson
2007/9/19, wasabifan <bryan.rickman(a)kewill.com>:
Sure. Here is one example (though I think it may have an
existential/universal not error as mentioned in another post):
rule "6040 Pass CA Fees"
when
#conditions
$status : ValidationPassFailStatus()
exists ValidationControl(validationNo == 6040)
CiLines($ciNo : ciNo, $ciLineNo : ciLineNo,
$countryOrigin :
countryOrigin)
Country(country == $countryOrigin, canadianProvince != "",
canadianProvince != "N")
(CiLineFees(amtFee == 0, ciNo == $ciNo, ciLineNo ==
$ciLineNo)
or not CiLineFees(ciNo == $ciNo, ciLineNo == $ciLineNo))
then
#actions
System.out.println("6040 Pass CA Fees");
$status.passSq(6040);
end
I have tried this with and without the parenthesis for explicitness. It
errors out when inserting facts for the rule:
java.lang.ClassCastException:
com.kewill.icustoms.customs.rules.model.ValidationPassFailStatusShadowProxy
at
org.drools.base.com.kewill.icustoms.dbi.model.CiLines$getCountryOrigin.getValue
(Unknown
Source)
at
org.drools.base.extractors.BaseObjectClassFieldExtractor.getHashCode(
BaseObjectClassFieldExtractor.java:139)
at
org.drools.base.ClassFieldExtractor.getHashCode(ClassFieldExtractor.java
:173)
at org.drools.rule.Declaration.getHashCode(Declaration.java:272)
at
org.drools.util.AbstractHashTable$SingleIndex.hashCodeOf(
AbstractHashTable.java:489)
at
org.drools.util.TupleIndexHashTable.getOrCreate(TupleIndexHashTable.java
:280)
at org.drools.util.TupleIndexHashTable.add(
TupleIndexHashTable.java:192)
at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:111)
...
However, if I break this into two separate rules, it behaves as expected
(with the possible existensial/universal logic problem I mention above).
rule "6040 Pass CA Fees"
when
#conditions
$status : ValidationPassFailStatus()
exists ValidationControl(validationNo == 6040)
CiLines($ciNo : ciNo, $ciLineNo : ciLineNo,
$countryOrigin :
countryOrigin)
Country(country == $countryOrigin, canadianProvince != "",
canadianProvince != "N")
CiLineFees(amtFee == 0, ciNo == $ciNo, ciLineNo ==
$ciLineNo)
then
#actions
System.out.println("6040 Pass CA Fees");
$status.passSq(6040);
end
rule "6040 Pass CA No Fees"
when
#conditions
$status : ValidationPassFailStatus()
exists ValidationControl(validationNo == 6040)
CiLines($ciNo : ciNo, $ciLineNo : ciLineNo,
$countryOrigin :
countryOrigin)
Country(country == $countryOrigin, canadianProvince != "",
canadianProvince != "N")
not CiLineFees(ciNo == $ciNo, ciLineNo == $ciLineNo)
then
#actions
System.out.println("6040 Pass CA No Fees");
$status.passSq(6040);
end
Edson Tirelli-3 wrote:
>
>
> As we speak, there is no known problem in the use of this
functionality
> in 4.0.1.
>
> Can you please provide an example of the problems you are finding?
>
> Thanks,
> Edson
>
>
>
--
View this message in context:
http://www.nabble.com/Arbitrary-problem-using-OR--tf4481210.html#a12779845
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
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
6236
days inactive
6236
days old
3 comments
2 participants
participants (2)
-
Edson Tirelli -
wasabifan