Булевские флаги, выполняющие условия Drools

Question

Мы работаем над приложением мониторинга, в котором мы следим за обработкой задачи в наборе приложений. У нас есть набор правил слюни, соответствующих нашим потребностям, но у нас есть некоторые проблемы с производительностью (у нас может быть легко до 50 тыс. Объектов в сеансе). Мы ищем лучшие pactices

Этот вопрос касается использования флага bloolean. Мы работаем для удаления большей части из org.drools.core.rule.constraint.MvelConstraint: Exception jitting: ... предупреждений.

Мы часто предупреждаем о булевых флагах.

, например, в:

rule "PropagateDeprecation" 
when 
    $parent:BaseChainStep($parent.Deprecated) 
    $child:BaseChainStep($parent.Id == $child.Parent, !$child.Deprecated) 
then 
    modify($child){ 
     setDeprecated(true) 
    } 
end 

мы должны предупредить как на $ parent.Deprecated и $ child.Deprecated!.

Мы хотели бы понять, почему существует предупреждение для булевых флагов.

Мы хотели бы знать также последствия предупреждения на сложенных условиях. Например в:

rule "App1_TriggerExpected" 
when $chainStep:App1ChainStep(
     HasChain 
     , HasParent 
     , !$chainStep.Deprecated 
     , Status in ("error", "closed") 
     , Places != null 
     , Analysis != null) 
then 
    .. 
end 

если мы Предупреждать о первом состоянии HasChain, как разрешило когда положение? Также оцениваются другие условия (с итерацией по всем объектам App1ChainStep), или какой-то «индекс» по-прежнему используется?

Если его вопрос, мы используем флаги как логические (а не булевы), чтобы обеспечить значение false по умолчанию.

Edit:

Проблема может быть связана с расширенных классов. В нашем случае использования у нас есть что-то вроде:

declare BaseChainStep 
    parent : GUID 
    deprecated : boolean 
end 

declare App1ChainStep extends BaseChainStep 
    // specific App1 fields 
end 

BaseChainStep поля можно манипулировать в правилах, использующих объекты App1ChainStep или объекты BaseChainStep.

rule "deprecateApp1" 
when $app1:App1ChainStep(BusinessLogicCondition) 
then 
     modify($app1) { 
      setDeprecated(true) 
     } 
end 

Затем флаг, устаревший, распространяется на детей App1 с использованием правила «PropagateDeprecation».

Булевский флаг, вызывающий предупреждение, объявляется в классе BaseChainStep.

Answer 1

Хотя вы отклоняетесь от обычного способа доступа к атрибутам, это не должно вызывать предупреждение, о котором вы сообщили. Я не могу воспроизвести это с помощью 6.3.0. Вы должны добавить (a) версию Drools (b) код Java для класса BaseChainStep, с которым проблема может быть воспроизведена с помощью правила, как показано.

Это еще один (гораздо проще) способ правила написания комбинируя логические атрибуты:

rule bool1 
when 
    X(big, fast) 
then 
    System.out.println("big fast X"); 
end 

Вы даже можете использовать логические операторы:

rule bool2 
when 
    X(big && ! fast) 
then 
    System.out.println("big slow X"); 
end 

Примечание простое использование имени поля, предполагая, что обычные например, big для поля, isBig и setBig для аксессуаров.