Zack,
The use of rule names as part of your logic (LHS) is a bad practice (as
you noticed already) for many reasons. I discussed this yesterday during my
presentation at the Rules Fest... I will make the presentation available
later this week.
I think the problem is that you are mixing data driven constraints with
rule explicit constraints. There are several ways of improving your rules
depending on your goals. For instance, if your AlertThreshold is supposed to
constrain your instance, then it should "know" which attribute should be
tested. Using a strategy pattern (or simply method overload if you prefer),
you could have the method testing your instance directly:
$entity : TestedEntity( )
AlertThreshold( entity == $entity, isOverThreshold( $entity ) )
Another way is to have an ENUM for the type of threshold you are dealing
with. This will avoid arbitrarily creating dependencies between facts and
rules.
$entity : TestedEntity( )
AlertThreshold( entity == $entity, type == ThresholdType.TEMPERATURE,
maxThreshold < $entity.temp )
My .02c. Hope it helps,
Edson
2011/10/25 zstlaw <zstlawre(a)akamai.com>
Each item I am testing MAY have overridden the default thresholds or
disable
the rule entirely. I would prefer to have this data related to the item I
am testing rather than have each rule manage customized behavior for
thousands of different types of objects.
The object could have a map of rule thresholds it overrides, but for
simplicity I assume there is a method to return the current threshold for
the current object. is there a better way to perform this kind of logic?
Example of my current code:
declare TestedEntity
temp : Double
end
declare AlertThreshold
maxAllowed : Double
end
rule "Check temperature"
when
$entity : TestedEntity( )
// would prefer to use drools.getRule().getName() on next line
AlertThreshold($entity.temp > maxAllowed) from
$entity.getAlertThresholdForRule("Check temperature")
then
// raise alert
end
I dislike hard-coding the rule name as it leads to copy paste errors. I
can't insert thresholds easily unless I define different ones for each rule
and I want to be able to fall back to defaults easily. This is a type of
problem I have come up against several times now so I feel like others must
have dealt with it before. The idea of writing copies of rules tailored to
each Entity appeals less than a generalized way of doing this. By doing
this I want to contain complexity. Dozens of slightly different
implementations of the same rule would be much harder to test and support.
I am dealing with hundreds of thousands of facts today and will need to
scale to millions before I can deploy fully. But with that large number I
need to have ways to manage exceptions to the general case just to keep
complexity manageable.
Thanks,
Zack
--
View this message in context:
http://drools.46999.n3.nabble.com/Advice-on-varying-rule-behavior-based-o...
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
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com