bitflicker64 commented on code in PR #503:
URL: https://github.com/apache/hugegraph-doc/pull/503#discussion_r4314136602
##########
content/en/docs/clients/restful-api/edge.md:
##########
@@ -416,12 +416,29 @@ It is not possible to delete an attribute that is not set
as nullable.
- vertex_id: Vertex ID
- direction: Edge direction (OUT | IN | BOTH), default is BOTH
- label: Edge label
-- properties: Key-value pairs of properties (requires pre-built indexes for
property queries)
+- properties: Key-value pairs of properties (see index coverage below)
- keep_start_p: Default is false. When set to true, the range matching input
expression will not be automatically escaped. For example,
`properties={"age":"P.gt(0.8)"}` will be interpreted as an exact match, i.e.,
the age property is equal to "P.gt(0.8)"
- offset: Offset, default is 0
- limit: Number of queries, default is 100
- page: Page number
+Without `vertex_id`, a `properties` query searches edges globally. When
`label` is specified, only indexes created on that label are used, and that
label needs
Review Comment:
Important: "When `label` is specified, only indexes created on that label
are used" no longer matches apache/hugegraph#3243 for sub-edge labels. Its
newest head 3b597b7 ("fix(server): complete sub-edge index plans", committed
2026-10-19 10:06 UTC, after this doc head) lets an explicit sub-label query use
the parent's index.
At 3b597b7:
- `GraphIndexTransaction.querySchemaLabels()` returns `[subLabel, father]`
when the single `LABEL` condition is a sub-edge label (`hasFather()`), so the
parent goes through the same visibility filter and index matching.
- `collectMatchedIndexes()` stops at the sub-label's own index when it has a
compatible one; otherwise the parent's `MatchedIndex` is used, and
`prepareIndexQuery()` rewrites the query to `SUB_LABEL = <sub-label>` so
sibling sub-labels are filtered out.
- `SourceIndexCoverageTest.testLabeledSubEdgeUsesParentIndex` creates an
index only on the base label `parentEdge` and asserts that
`E().hasLabel("subA").has("coverageName", "same")` returns the `subA` edge and
not the `subB` one. With `parentEdge` set to `DELETING` the same query throws
`NoIndexException`. `testLabeledSubEdgeUsesParentRangeJointAndSearchIndexes`
covers range, joint and search indexes. The memory and RocksDB server test jobs
passed at 3b597b7.
- `EdgeAPI.list` builds `g.traversal().E().hasLabel(label)` for `label`
without `vertex_id`, so `GET
.../graph/edges?label=subA&properties={"coverageName":"same"}` takes this path.
So once #3243 merges at this head, a reader who passes a sub-edge `label`
will expect an index error, or create a redundant index on the sub-label, when
the parent index already serves the query. The "When `label` is omitted,"
qualifier on line 429 was added for the earlier 7f5a917 behaviour, and that
behaviour has now changed. On `master` (fd8d06c) and 1.7.0,
`collectMatchedIndexes()` still reads only the specified label's
`indexLabels()`, so the current sentence is right only for released versions.
Requested change: describe the #3243 behaviour and put the old behaviour
under the existing version note, for example: "When `label` is specified, that
label needs a compatible property index; for a sub-edge label without one, a
compatible index on its query-visible parent label is used and edges of sibling
sub-labels are filtered out." Then add to the version note on lines 433-434:
"earlier versions use only indexes created on the specified label." Mirror it
in content/cn/docs/clients/restful-api/edge.md line 431 ("指定 `label`
时，仅使用该标签上建立的索引") and its version note on line 436. If #3243 changes this again
before it merges, please re-check this paragraph against its final head.
--
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]
