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@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-on-object-tested-tp3452814p3452814.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users



--
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com