[
https://issues.apache.org/jira/browse/TINKERPOP-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17768347#comment-17768347
]
ASF GitHub Bot commented on TINKERPOP-2423:
-------------------------------------------
rdtr opened a new pull request, #2254:
URL: https://github.com/apache/tinkerpop/pull/2254
We may want to do away with XOR for hashCode computation for everything, but
for now I only limit those whose keys for XOR are very simple and can be
duplicate.
Duplicate keys are canceled with each other when XOR is applied, that is the
problem and a different Step can be considered as "equal" as consequence.
This CR fixes the issue.
> hashCode collision for steps with different attributes
> ------------------------------------------------------
>
> Key: TINKERPOP-2423
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2423
> Project: TinkerPop
> Issue Type: Bug
> Components: process
> Affects Versions: 3.4.8
> Reporter: Saikiran Boga
> Priority: Major
>
> The {{hashCode computation}} for PropertiesStep collides for multiple steps
> when there are repeating keys. For example {{.properties()}} and
> {{.properties("a","a")}}, {{.properties("a")}} and
> .{{properties("a","b","b")}} have the same hash code because of xor of just
> properties here
> [https://github.com/apache/tinkerpop/blob/cff4c161615f2b50bda27b6ba523c7f52b833532/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/PropertiesStep.java#L80-L87].
> Basically, the even keys cancel out the xor computation.
>
> The same is also true for {{AbstractStep.hashCode}} which takes xor of labels.
> {{GraphStep}} does the same thing using ids. so {{g.V("1", "1")}} and
> {{g.V()}} would collide during comparison.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
