contrueCT commented on code in PR #2994:
URL: https://github.com/apache/hugegraph/pull/2994#discussion_r4089539763
##########
hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/backend/tx/GraphIndexTransaction.java:
##########
@@ -768,11 +771,12 @@ private PageIds doIndexQueryOnce(IndexLabel indexLabel,
@Watched(prefix = "index")
private Set<MatchedIndex> collectMatchedIndexes(ConditionQuery query) {
ISchemaTransaction schema = this.params().schemaTransaction();
- Id label = query.condition(HugeKeys.LABEL);
+ Set<Object> labels = query.conditionValues(HugeKeys.LABEL);
List<? extends SchemaLabel> schemaLabels;
- if (label != null) {
- // Query has LABEL condition
+ if (labels.size() == 1) {
Review Comment:
Fixed in a4805373. Removing the guard in the previous merge was my mistake;
my targeted validation omitted this existing Vertex regression. Both
collectMatchedIndexes() and queryByUserprop() now reject empty EQ/IN LABEL
intersections. The range-index cleanup path explicitly skips an unmatched index
label instead of relying on an assertion, with a regression exercising that
null case.
The existing testCollectMatchedIndexesByJointLabelsWithIndexedProperties and
testQueryByUserpropWithConflictingLabels passed on both Memory and RocksDB.
Java 17 validation: 54 unit tests passed; Memory core selection passed 37 with
8 skipped; RocksDB passed 44 with 1 skipped. Formatting and all-module clean
compilation passed. This is targeted validation, not a full HStore/distributed
matrix or a claim about CI results.
##########
hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/traversal/optimize/TraversalUtil.java:
##########
@@ -173,6 +189,10 @@ public static void trySetGraph(Step<?, ?> step, HugeGraph
graph) {
public static void extractHasContainer(HugeGraphStep<?, ?> newStep,
Traversal.Admin<?, ?> traversal) {
+ if (hasUnsafeLabelInTraversal(traversal, newStep)) {
Review Comment:
Addressed the minimum scope-narrowing request in a4805373. A child scan now
stops at a proven element-changing suffix that cannot recover the source
element. In particular, where(__.out().hasLabel(P.neq(...))) and
not(__.out().hasLabel(...)) no longer disable the source property's index path.
Runtime tests verify that an unindexed source property still raises
NoIndexException in those cases.
Plan regressions cover where/filter/not and outE().inV(), while same-element
labels and select/path recovery retain the conservative fallback. Existing
ancestor/repeat and negative-label regression selections passed on Memory and
RocksDB. No configuration was added: this does not claim to eliminate the
fallback for the same element or unknown provenance; broader index-coverage
work remains tracked by #3201. The PR description and linked Gist now state
this boundary explicitly.
##########
docs/negative-label-queries.md:
##########
@@ -0,0 +1,64 @@
+# Negative-label queries and local filtering
Review Comment:
The repository copy was removed in 16786e93. Per the contributor’s requested
scope, the explanatory note is maintained only in the Gist linked from the PR
body, with no fork-hosted document link. The PR no longer describes a
repository copy, and the Gist has now been updated for the narrowed
child-traversal scope. This does not claim that an official website
documentation change has been published.
--
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]
