Muss eine InverseRelationShadowVariable notwendigerweise zu einer planningEntity gehören?

Question

Ich habe versucht, eine Schattenvariable zu implementieren, so dass eines meiner Problemfakten verfolgen kann, welche Planungseinheit für sie relevant ist. Das Endziel ist, meine Regeln zu vereinfachen/zu beschleunigen.

Ich schaue auf die optaplanner doc about shadow variables, insbesondere das CloudBalancing-Beispiel. Im "normalen" CloudBalancing ist die Klasse CloudComputernicht eine planningEntity. Im folgenden Beispiel ist es jedoch als planningEntity gekennzeichnet.

Sollen wir verstehen, dass die Klasse, die die Schattenvariable hostet, eine Planungseinheit sein sollte? Ich dachte, eine PlanungEntity müsste eine Planungsvariable haben, aber CloudComputer nicht. Wenn die Antwort ja lautet, schlage ich vor, in der Dokumentation ausführlicher darüber zu sein. Wenn die Antwort nein ist, liegt ein Fehler in diesem Beispiel vor (die Annotation @PlanningEntity sollte aus CloudComputer entfernt werden).

Das folgende Beispiel aus dem doc ist:

Für eine nicht-verkettete Planung Variable, die bidirektionale Beziehung eine viele zu einer Beziehung sein muss. Um eine bidirektionale Beziehung zwischen zwei Planungsvariablen abzubilden, mit Anmerkungen versehen, die Master-Seite (die Original-Seite ist) als eine normale Planungsvariable:

@PlanningEntity 
public class CloudProcess { 

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

} 

Und:

@PlanningEntity 
public class CloudComputer { 

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

} 

Auch dieses ist wirklich alles, was benötigt wird, damit die processList auch dann aktuell bleibt, wenn CloudProcess beim Lösen geklont wird?

Answer 1

Es gibt zwei Arten von Planungsvariablen: echte (@PlanningVariable) und Schattenvariablen. Jede Klasse, die eine oder eine Kombination davon hat, muss als @PlanningEntity kommentiert werden (und zur Solver-Konfiguration hinzugefügt werden, sofern Sie nicht scanAnnotatedClasses verwenden).

Ja, dies ist wegen der Planung Klonen. Mit der Shadow-Variable ändert sich CloudComputer während der Planung nicht und muss daher nicht geklont werden. Mit der Schattenvariablen ändert sie sich während der Planung und muss daher geklont werden. Wenn es nicht geklont werden würde, würde die beste Lösung beschädigt werden, wenn sich die interne Arbeitslösung ändert. Dies hätte wiederum Auswirkungen auf die Score-Berechnung (wenn die inverse Liste verwendet wird) und auf alle Consumer-Ereignisse mit der besten Lösung oder auf das beste Lösungsergebnis, das von solve() zurückgegeben wird.