contrueCT commented on code in PR #2994:
URL: https://github.com/apache/hugegraph/pull/2994#discussion_r3596863175
##########
hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/backend/tx/GraphIndexTransaction.java:
##########
@@ -773,7 +783,8 @@ private Set<MatchedIndex>
collectMatchedIndexes(ConditionQuery query) {
}
schemaLabels = ImmutableList.of(schemaLabel);
} else {
- // Query doesn't have LABEL condition
+ // Query doesn't have LABEL condition or it doesn't resolve
+ // to a single label, so keep the conservative fallback.
if (query.resultType().isVertex()) {
schemaLabels = schema.getVertexLabels();
Review Comment:
I traced this through the production query path, and the proposed
partial-plan path is not reachable.
`GraphTransaction.optimizeQueries()` calls
`ConditionQueryFlatten.flatten(query, supportIn)` before the only production
call to `GraphIndexTransaction.queryIndex()`. In `convIn2Or()`, `supportIn`
preserves `IN` only for `OWNER_VERTEX`/`ID`; `LABEL IN` is always expanded into
per-label `EQ` queries. In a focused test, `flatten(query, true)` produced two
single-label queries. With A and C indexed and B unindexed, `hasLabel(A,
B).has(city, Beijing)` raised `NoIndexException` for B instead of silently
returning A or selecting C's unrelated index. Directly invoking
`collectMatchedIndexes()` with an unflattened `LABEL IN` bypasses that
invariant.
As a secondary scope point, current master documents MySQL/Cassandra as
legacy backends available in versions <= 1.5.0, and `install-backend.sh`
reports both unsupported since 1.7.0. Therefore I don't think a planner change
or a MySQL/Cassandra runtime regression is required for this thread.
##########
hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/backend/serializer/TextSerializer.java:
##########
@@ -516,6 +516,17 @@ private Query writeQueryEdgePrefixCondition(ConditionQuery
cq) {
return null;
}
+ private Object edgeIdConditionValue(ConditionQuery cq, HugeKeys key) {
+ if (key == HugeKeys.LABEL) {
+ /*
+ * LABEL may still be represented by multiple top-level EQ/IN
+ * relations before strict edge-id serialization.
+ */
+ return cq.conditionValue(key);
Review Comment:
I checked the full edge-query path. Both
`GraphTransaction.queryEdgesFromBackend()` and the common `optimizeQueries()`
path flatten condition queries before backend serialization. The same
`convIn2Or()` rule applies when `supportIn == true`: only `OWNER_VERTEX`/`ID`
may retain `IN`; `LABEL IN [A, B]` becomes two single-label queries.
A direct call to `TextSerializer.writeQuery()` with an artificially
unflattened multi-label query does reproduce the `conditionValue(LABEL)`
exception, but that bypasses the production invariant. After applying the real
pre-serialization flatten step, the focused test produced two single-label
queries and both serialized successfully. Thus `outE(labelA, labelB)` cannot
reach this fast path with multiple LABEL values through `GraphTransaction`.
Also, MySQL is documented as a legacy backend available only in versions <=
1.5.0, and `install-backend.sh` reports it unsupported since 1.7.0. A
MySQL-profile runtime regression should not be required for the current
supported-backend scope.
--
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]
