InverseRelationShadowVariable은 반드시 planningEntity에 속해야합니까?

Question

나는 내 문제 사실 중 하나가 어떤 계획 엔티티와 관련이 있는지 추적 할 수 있도록 쉐도우 변수를 구현하려고 시도했다. 최종 목표는 내 규칙을 단순화/가속화하는 것이다.

나는 optaplanner doc about shadow variables, 특히 cloudBalancing 예를보고 있습니다. "정상적인"클라우드 밸런싱에서 CloudComputer 클래스는 이 아니며 PlanningEntity입니다. 그러나 아래 예제에서는 planningEntity로 주석 처리되어 있습니다.

그림자 변수를 호스팅하는 클래스가 계획 엔티티 여야한다는 것을 이해해야합니까? planningEntity가 PlanningVariable을 가져야한다고 생각했지만 CloudComputer은 그렇지 않습니다. 대답이 '예'인 경우, 설명서에서 이에 대해 더 명확하게 설명하는 것이 좋습니다. 대답이 '아니오'인 경우이 예에서 실수가 있습니다. @PlanningEntity 주석은 CloudComputer에서 삭제해야합니다.

다음 예는 문서에서이다

비 계획 체인 변수, 쌍방향 관계가 일대일 관계로 많이해야한다.

@PlanningEntity 
public class CloudProcess { 

    @PlanningVariable(...) 
    public CloudComputer getComputer() { 
     return computer; 
    } 
    public void setComputer(CloudComputer computer) {...} 

} 

: 그리고 통상 계획 변수 (정품 측 인) 마스터 측 주석 두 계획 변수 사이의 쌍방향 관계를 매핑하는 것도

@PlanningEntity 
public class CloudComputer { 

    @InverseRelationShadowVariable(sourceVariableName = "computer") 
    public List<CloudProcess> getProcessList() { 
     return processList; 
    } 

} 

, 이것이 정말 문제를 해결하는 동안 CloudProcess이 복제 되더라도 processList가 최신 상태로 유지되는 데 필요한 모든 작업이 필요합니까?

Answer 1

2 가지 종류의 계획 변수가 있습니다 : 정품 (@PlanningVariable)과 쉐도우 변수. 둘 중 하나 또는 그 조합을 가진 클래스는 @PlanningEntity으로 주석을 추가해야합니다 (scanAnnotatedClasses를 사용하지 않는 한 해석자 구성에 추가됨).

예, 이는 계획 복제 때문입니다. 그림자 변수를 사용하면 CloudComputer가 계획 중에 변경되지 않으므로 복제 계획을 세울 필요가 없습니다. 그림자 변수는 계획 중에 변경되므로 복제해야합니다. 복제 계획을 세우지 않으면 내부 솔루션이 변경 될 때 최상의 솔루션이 손상 될 수 있습니다. 그 결과 역서 목록을 사용하는 경우 점수 계산 및 최상의 솔루션 이벤트 소비자 또는 solve()에 의해 반환 된 최상의 솔루션 결과에 영향을 미칩니다.