Join-Monster 中联合类型字段解析的优化与修复

问题背景

在 GraphQL 查询中，联合类型(Union Type)是一种常见的模式，它允许一个字段返回多种可能的类型。Join-Monster 作为 GraphQL 到 SQL 的转换工具，在处理这种联合类型时遇到了一个有趣的边界情况：当查询中请求了同一联合类型下不同成员类型的相同字段但不同子字段时，会出现数据丢失的问题。

问题现象

具体表现为：当查询一个联合类型字段时，如果在该联合类型的不同成员类型中都请求了相同的字段（如"author"），但每个成员类型请求了该字段的不同子字段（如"capitalizedLastName"和"email"），Join-Monster 会随机保留其中一个子字段而丢弃另一个。

例如，在查询用户创作内容时：

{
  user(id: 1) {
    writtenMaterial1 {
      ... on Comment {
        id
        author {
          capitalizedLastName
        }
      }
      ... on Post {
        id
        author {
          email
        }
      }
    }
  }
}

结果中，要么只有 capitalizedLastName 有值而 email 为 null，要么相反，即使底层数据中这两个字段都有有效值。

问题根源

通过分析源代码，发现问题出在联合类型解析过程中。Join-Monster 在处理联合类型时，会为每个可能的类型生成带后缀的字段名（如"author@Comment"和"author@Post"）。但在最终合并结果时，它只是简单地选择第一个遇到的非空字段，而不会根据实际的类型信息来正确选择对应的字段。

解决方案

修复方案采用了对象合并的策略：当发现有多个对象需要合并到同一字段时，不是简单地覆盖，而是递归地合并它们的属性。这样确保了所有请求的子字段都能被保留。

具体实现分为两部分：

1. 对于普通连接模式(join mode)，在 resolve-unions.js 中修改了字段合并逻辑
2. 对于批处理模式(batch mode)，在 batch-planner/index.js 中做了类似的修改

合并策略示例：

{ author: { capitalizedLastName: "..." } }  
+ 
{ author: { email: "..." } } 
= 
{ author: { capitalizedLastName: "...", email: "..." } }

技术启示

这个修复展示了 GraphQL 实现中几个重要的设计考虑：

1. 字段解析顺序不应影响结果：GraphQL 规范强调查询结果不应依赖于内部执行顺序，这个修复确保了这一点。

2. 联合类型的完整解析：即使客户端只请求了部分字段，服务端也应完整保留所有可能的字段，直到最后的字段选择阶段。

3. 批处理与普通模式的统一：需要确保不同执行模式下行为的一致性，这对库的使用者来说非常重要。

总结

Join-Monster 通过这次修复，完善了对 GraphQL 联合类型字段的处理能力，特别是在处理"分离字段"(disjoint fields)场景时更加健壮。这不仅解决了具体的问题，也为类似 GraphQL 工具的开发提供了有价值的参考：在处理复杂类型系统时，需要特别注意字段合并策略的设计。