我一直在尝试实现影子变量，以便我的一个问题事实可以跟踪哪个规划实体与其相关，最终目标是简化/加速我的规则。
我正在查看 optaplanner doc about shadow variables ，尤其是 cloudBalancing 示例。在“正常”的 cloudBalancing 中，CloudComputer 类不是 planningEntity。但在下面的示例中，它被注释为 planningEntity。
我们是否理解“托管”影子变量的类应该是一个规划实体？我认为 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 是否真的只需要保持最新状态？
最佳答案
有两种规划变量:真正的(@PlanningVariable)和影子变量。任何具有其中之一或其组合的类都需要注释为 @PlanningEntity(并添加到求解器配置中，除非您使用的是 scanAnnotatedClasses)。
是的，这是因为计划克隆。使用影子变量，CloudComputer 在规划期间不会更改，因此不需要规划克隆。有了影子变量，在规划的时候会发生变化，所以需要clone。如果它不计划克隆，那么当内部工作解决方案发生变化时，最好的解决方案就会被破坏。这反过来会影响分数计算(如果它使用逆列表)和最佳解决方案事件的任何消费者或 solve() 返回的最佳解决方案结果。
关于java - InverseRelationShadowVariable 必须属于 planningEntity 吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37751009/