from vs fromUnfiltered with nullable variable - Optaplanner

Question

我需要澄清 from 和 fromUnfiltered 在 Optaplanner 中使用 planningEntities 和 nullable 变量时的行为。

user documentation 声明

.from(T) 构建块选择问题事实集合或计划实体集合中的每个 T 实例，并且没有空计划变量。

要包含具有空计划变量的实例，特别是如果您使用可空变量，请将 from() 构建块替换为 fromUnfiltered()：

但是from 方法的java doc 声明from 方法将过滤具有空变量的实体，除非它是nullable 变量：

启动 fromClass 的所有实例的 ConstraintStream，这些实例称为问题事实或规划实体。

如果fromClass是一个PlanningEntity，那么它将被自动过滤为只包含完全初始化的实体，每个真正的PlanningVariable（fromClass或其超类的）都被初始化（所以当值不为null时- 除非 PlanningVariable.nullable() 被修改）。此过滤不会自动应用于 fromClass 的子类规划实体的真正规划变量。

我不确定我的理解是否正确，我的测试表明 javadoc 是正确的，而用户文档具有误导性。或者也许我没有抓住重点。

有人澄清一下吗？

Answer 1

from(...) 的整个情况已经痛苦了一段时间。 OptaPlanner 8.13.0.Final 及更早版本中的行为如下：

• 对于具有 nullable = false 计划变量（默认值）的实体，from(...) 仅返回其真正计划变量中没有 null 的实体。
• 对于具有nullable = true 计划变量（过度约束的计划）的实体，from(...) 在初始化这些实体后仍会在其任何真正的计划变量中返回具有null 的实体。换句话说 - 它不会在构造启发式期间返回它们，但如果构造启发式决定将null 保留在此处，它将在随后的本地搜索中返回它们。

但是，在处理null 时，这并不是唯一令人困惑的行为。通过条件传播（ifExists(...) 等），我们将始终在任何情况下返回具有 null 真实变量的实体。

我们最近意识到这种情况是不可持续的，从 OptaPlanner 8.14.0.Final（即将发布）开始，我们已弃用 from(...) 并引入了 forEach(...)，它清理了所有这些混乱。从这个版本开始，使用新的 API 时，null 变量的行为将更加清晰，更重要的是，更加一致。

forEach(...) 将永远返回带有null 变量的实体，应该使用forEachIncludingNullVars(...)。条件传播也会尊重这一点。

当新版本发布时，请参阅upgrade recipe。