InverseRelationShadowVariable 必须属于 planningEntity 吗？

Question

我一直在尝试实施影子变量，以便我的一个问题事实可以跟踪哪个规划实体与其相关，最终目标是 simplify/speed 我的规则。

我正在查看 optaplanner doc about shadow variables，尤其是 cloudBalancing 示例。在 "normal" 云平衡中，class CloudComputer 不是规划实体。但在下面的示例中，它被注释为 planningEntity。

我们是否理解class"hosting"影子变量应该是规划实体？我认为 planningEntity 必须有 planningVariable，但 CloudComputer 没有。 如果答案是肯定的，我建议在文档中更明确地说明它。如果答案是否定的，则此示例中存在错误（应从 CloudComputer 中删除 @PlanningEntity 注释）。

以下示例来自文档：

对于非链式规划变量，双向关系必须是多对一关系。要映射两个规划变量之间的双向关系，将主侧（即真实侧）注释为正常规划变量：

@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

规划变量有两种：真实变量（@PlanningVariable）和影子变量。任何具有其中之一或其组合的 class 都需要注释为 @PlanningEntity（并添加到求解器配置中，除非您使用的是 scanAnnotatedClasses）。

是的，这是因为计划克隆。使用影子变量，CloudComputer 在规划期间不会更改，因此不需要规划克隆。有了影子变量，在规划的时候会发生变化，所以需要clone。如果它不计划克隆，那么当内部工作解决方案发生变化时，最好的解决方案就会被破坏。这反过来会影响分数计算（如果它使用反向列表）和最佳解决方案事件的任何消费者或 solve().

返回的最佳解决方案结果。

InverseRelationShadowVariable 必须属于 planningEntity 吗？

Must an InverseRelationShadowVariable necessarily belong to a planningEntity?

java

optaplanner