GraphScope中长整型字面量查询生成错误哈希码的问题解析

在GraphScope图计算引擎中，我们发现了一个关于长整型(i64)字面量在查询处理过程中被错误识别为整型(i32)的问题。这个问题会影响使用长整型字面量作为查询条件的正确性。

问题现象

当执行以下两种查询时：

g.V().hasLabel('PERSON').has('id', 1)
g.V().hasLabel('PERSON').has('id', 1L)

理论上，第一个查询中的1应该被识别为i32类型，而第二个查询中的1L应该被识别为i64类型。然而在实际执行中，第二个查询生成的物理计划中，1L也被错误地识别为i32类型。

问题分析

这个问题源于查询解析和物理计划生成阶段对字面量类型的处理不够严谨。在Gremlin查询中，数字字面量默认会被解析为整型(i32)，而带有L后缀的则应该明确解析为长整型(i64)。

在GraphScope的查询处理流程中，哈希码生成阶段没有充分考虑类型后缀的影响，导致类型信息丢失。具体表现为：

1. 查询解析器正确识别了1和1L的区别
2. 但在生成物理计划时，类型信息没有被正确传递
3. 最终生成的查询计划中，所有数字字面量都被统一处理为i32类型

技术影响

这种类型识别错误会导致以下潜在问题：

1. 当属性值实际存储为i64类型时，查询可能无法正确匹配
2. 在分布式环境下，不同节点可能对同一查询生成不同的执行计划
3. 对于大数据量的属性值(超过i32范围)，查询结果会不准确

解决方案

该问题已在最新版本中修复，主要改进包括：

1. 增强查询解析器对类型后缀的识别能力
2. 在物理计划生成阶段保留原始类型信息
3. 确保哈希码生成考虑类型差异

修复后，查询计划现在能正确区分i32和i64类型的字面量，确保查询执行的准确性。

最佳实践

对于GraphScope用户，在处理可能超过i32范围的ID或属性值时，建议：

1. 明确使用L后缀表示长整型
2. 检查重要查询生成的物理计划，确认类型处理正确
3. 对于关键业务查询，进行边界值测试

这个问题提醒我们在图数据库查询中，类型系统的严谨性对查询结果的准确性至关重要。即使是看似简单的数字字面量，也需要正确处理其类型信息。