Drools 8.40.0+中‘is not relevant to this pattern’警告原因咨询

问题背景 #

在使用Drools 8.40.0及以上版本编写规则时，触发了“$si is not relevant to this pattern”警告，该警告源于PR#5270。将规则改写后警告消除，以下是具体分析：

触发警告的规则 #

rule "Sample-Denied"
no-loop
when
  $req: Request()
  $si: SessionInfo()
  $settings: Settings()
  DataAccessor (
    $si.score < $settings.requiredScore(getProperty($req.key()), $si.sessionType)
  )
  $response: Response()
then
  modify($response){
    denied()
  };
end

警告内容 #

|o.d.mvel.MVELConstraint|| $si is not relevant to this pattern, so it causes class reactivity. Consider placing this constraint in the original pattern if possible : $si.score < $settings.requiredScore(getProperty($req.key()), $si.sessionType)

改写后消除警告的规则 #

rule "Sample-Denied"
no-loop
when
  $req: Request()
  $settings: Settings()
  $da: DataAccessor()
  SessionInfo(
    score < $settings.requiredScore($da.getProperty($req.key()), sessionType)
  )
  $response: Response()
then
  modify($response){
    denied()
  };
end

警告消除的原因 #

1. 模式关联性的核心要求
   Drools规则引擎的模式匹配依赖于约束与对应对象模式的直接关联性。原规则中，DataAccessor模式的约束引用了外部绑定的$si（SessionInfo实例），但$si和DataAccessor模式没有任何直接关联——既不是DataAccessor的字段，也没有通过逻辑绑定到该模式。这种跨模式引用外部变量的写法，会让Drools无法精准追踪对象变化，只能触发类级反应性（即当SessionInfo类的任何实例属性变化时，都要重新评估所有DataAccessor实例的约束），性能成本更高，因此抛出警告。

2. 改写后的规则符合优化逻辑
   改写后的规则将原本在DataAccessor中的约束，移到了SessionInfo模式内部：

• 直接使用SessionInfo自身的score和sessionType属性，不再依赖外部绑定的$si变量
• 虽然仍引用了$settings和$da的外部变量，但核心属性比较是基于SessionInfo自身字段，Drools可以明确将约束与SessionInfo对象关联，只会在SessionInfo实例的属性变化时重新评估该模式，避免了类级反应性，满足了引擎的优化要求，因此警告被消除。

简单来说，Drools更希望你把和某个对象相关的约束，尽可能放在该对象对应的模式块中，这样能精准定位需要重新评估的实例，提升规则执行效率。

内容的提问来源于stack exchange，提问作者Aluveitie