bitflicker64 commented on code in PR #561: URL: https://github.com/apache/hugegraph-doc/pull/561#discussion_r4500717083
########## content/en/docs/language/hugegraph-gremlin.md: ########## @@ -138,3 +138,41 @@ please refer to the [Apache TinkerPop 3.8.1 official documentation](https://tink | `V` | Traversal steps between vertices and edges: `V`, `E`, `out`, `in`, `both`, `outE`, `inE`, `bothE`, `outV`, `inV`, `bothV`, and `otherV` | [vertex steps](https://tinkerpop.apache.org/docs/3.8.1/reference/#vertex-steps) | | `where` | Filters traversal results. Supports `eq`, `neq`, `lt`, `lte`, `gt`, `gte`, and `between` operators. | [where step](https://tinkerpop.apache.org/docs/3.8.1/reference/#where-step) | {.wide .expand} + +### Numeric Literal Type Matching in Gremlin-Groovy Predicates + +In Gremlin-Groovy, an unsuffixed decimal literal like `1.0` is parsed as `java.math.BigDecimal`, +and an unsuffixed integer literal like `1` is parsed as `java.lang.Integer`. When evaluating +predicates against property keys, mismatched literal types lead to two distinct behaviors in HugeGraph: + +- **Collection membership predicates (`P.within`, `P.without`):** HugeGraph passes the listed + values to its `IN` / `NOT_IN` query condition (`TraversalUtil.convIn2Relation`) without converting + them to the `PropertyKey` data type, and matches them using Java object equality + (`Collection.contains(value)`). Because `BigDecimal.valueOf(1.0).equals(Double.valueOf(1.0d))` and + `Integer.valueOf(1).equals(Long.valueOf(1L))` are both `false`, `has('weight', P.within(1.0))` + returns `0` results on a `DOUBLE` property even when `weight = 1.0`. Review Comment: Important: `P.within(1.0)` matches a stored `1.0d`, because `ConditionQueryFlatten.convIn2Or` turns `IN` into `EQ` conditions that compare numbers by value (`NumericUtil.compareNumber`). On 1.7.0 (memory and RocksDB), `g.E().has('weight', P.within(1.0)).count()` returns `1` with an index on `weight` and throws `NoIndexException` without one, suffix or not. Remove the zero-result claim and the `Collection.contains` explanation, here and in `propertykey.md`. ########## content/cn/docs/language/hugegraph-gremlin.md: ########## @@ -134,3 +134,43 @@ HugeGraph 支持 Gremlin 遍历规范定义的各项步骤。完整说明与高 | `V` | 顶点检索与端点跳转基础步骤：`V`、`E`、`out`、`in`、`both`、`outE`、`inE` 等 | [vertex steps](https://tinkerpop.apache.org/docs/3.8.1/reference/#vertex-steps) | | `where` | 使用表达式或谓词（`eq`、`neq`、`gt` 等）进行条件筛选过滤 | [where step](https://tinkerpop.apache.org/docs/3.8.1/reference/#where-step) | {.wide .expand} + + +### Gremlin-Groovy 数值字面量类型与属性谓词匹配规则 + +在通过 Gremlin-Groovy（例如 HTTP `/gremlin` 接口、HugeGraph-Console 或 HugeGraph-Hubble） +执行图查询时，Groovy 默认将不带类型后缀的小数字面量（如 `1.0` 或 `1.5`）解析为 +`java.math.BigDecimal`，将不带后缀的整数字面量（如 `1`）解析为 `java.lang.Integer`。在对属性键 +执行谓词过滤时，字面量类型不匹配会导致 HugeGraph 中的两类行为： + +- **集合包含谓词（`P.within`、`P.without`）：** HugeGraph 将列表中的值直接传给 `IN` / `NOT_IN` + 查询条件（`TraversalUtil.convIn2Relation`），不按 `PropertyKey` 数据类型进行转换，并基于 + Java 对象的 `Collection.contains(value)` 判等逻辑执行匹配。由于运行时类型不同， + `BigDecimal.valueOf(1.0).equals(Double.valueOf(1.0d))` 与 `Integer.valueOf(1).equals(Long.valueOf(1L))` + 均返回 `false`，当属性类型为 `DOUBLE` 且实际存储值为 `1.0` 时，`has('weight', P.within(1.0))` + 仍会返回 `0` 条结果。 Review Comment: Important: same problem as the English page: `ConditionQueryFlatten.convIn2Or` turns `IN` into value-compared `EQ` conditions, so `P.within(1.0)` matches a stored `1.0d` and never returns `0` for that reason. Remove the zero-result claim and the `Collection.contains` explanation, here and in `propertykey.md`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
