imbajin commented on code in PR #2994:
URL: https://github.com/apache/hugegraph/pull/2994#discussion_r3355123737
##########
hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/backend/serializer/BinarySerializer.java:
##########
@@ -674,7 +674,7 @@ private Query writeQueryEdgeRangeCondition(ConditionQuery
cq) {
if (direction == null) {
direction = Directions.OUT;
}
- Id label = cq.condition(HugeKeys.LABEL);
+ Id label = (Id) this.edgeIdConditionValue(cq, HugeKeys.LABEL);
Review Comment:
⚠️ The new `ConditionQuery` semantics are covered well at the helper level
and for the vertex index-selection regression, but this PR also changes several
edge/backend fast paths: `BinarySerializer`, `TextSerializer`,
`GraphTransaction`, `RamTable`, and `HstoreStore`.
For context, these call sites now choose between strict single-label
semantics (`conditionValue()`) and single-or-null semantics
(`uniqueConditionValue()`). That distinction is important for edge-id
prefix/range serialization and backend shortcut selection.
Could we add at least one edge end-to-end regression for `LABEL EQ + IN`
resolving to a single label, and one multi-label edge query with property or
sort-key conditions? That would protect the strict-vs-unique LABEL behavior in
the serializer/backend paths, not just the `ConditionQuery` helper itself.
--
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]
