Power-Fx 项目中 Join 操作符的 DValue 键值问题解析

问题背景

在 Power-Fx 项目中，Join 操作符的实现存在一个潜在的问题，它使用了 DValue/RecordValue 作为字典键值。这种实现方式在某些情况下会导致错误的查询结果。

问题重现

考虑以下 Power-Fx 表达式：

With({T1: [10,20]}, Join(T1, T1, LeftRecord.Value = 10 && RightRecord.Value = 20, JoinType.Left, RightRecord.Value As R2))

预期结果应该是为左表中的每一行都生成一条记录（因为使用了 JoinType.Left），即应该包含 {Value:20, R2 : blank } 这样的结果。然而实际执行却得到了不正确的输出：

  R2   Value
 ==== =======
  20   10

技术原理分析

这个问题的根源在于 Join 实现使用了 DValue 作为字典键值。DValue 是 Power-Fx 中表示数据值的基础类型，但存在以下关键问题：

1. 对象引用相等性问题：DValue 没有重写 .Equals 方法（也不应该重写，特别是 RecordValue 也不应该实现 .equals），导致字典比较实际上使用的是对象引用相等性而非值相等性。

2. 唯一性假设错误：Join 实现假设所有 DValue 都是唯一的，但这个假设并不成立。当相同的值被多次使用时，可能会被错误地识别为同一个键。

3. InMemoryTable 的缓解作用：目前大多数内置函数使用 InMemoryTable，它会始终分配新的 DValue 实例，这在一定程度上缓解了这个问题。但这不是根本解决方案，且存在被绕过的可能。

潜在影响

虽然当前 InMemoryTable 的实现方式减少了问题出现的概率，但以下情况仍可能导致问题：

1. 用户可以通过特定方式构造查询绕过 InMemoryTable 的保护机制
2. 未来的优化可能会扩大这个问题的暴露范围
3. 其他 TableValue 的实现可能不受 InMemoryTable 保护机制的影响

解决方案建议

根本的解决方案是避免使用 DValue 作为字典键值。可以考虑以下替代方案：

1. 使用索引而非值本身作为键值
2. 实现专门的比较逻辑来处理值相等性而非引用相等性
3. 为 Join 操作设计专门的键值生成机制，确保唯一性和正确性

结论

这个问题揭示了在函数式语言实现中处理值相等性的重要性。虽然当前有缓解措施，但从长远来看，重构 Join 实现以避免依赖 DValue 的引用相等性才是根本解决方案。这也提醒我们在设计数据操作符时需要特别注意值比较的语义问题。