PropertiesStep.hashcode() not always unique
As background...
We're working with Gremlin (groovy) to write queries against an in memory graph model implemented in java.
I've implemented a custom traversal strategy that will find all PropertiesStep instances in the traversal and prepend a custom step to each one (I could go into more detail but it's not actually relevant to my question).
While implementing the
This same logic is used by the built in
apply method of the strategy I was getting the index of the PropertiesStep instances using the indexOf method:
traversal.getSteps().indexOf(step)This same logic is used by the built in
ReferenceElementStrategy (maybe others but I haven't checked).
The problem is that indexOf was not always returning the correct index. After some digging I found that PropertiesStep.hashcode() does not necessarily return a unique value.
In my case, there were two instances of PropertiesStep in the traversal, both of which were returning the same value from PropertiesStep.hashcode().
I've managed to avoid using indexOf so this isn't blocking me in any way, I just thought it was worth bringing attention to.
I think it is a very rare case for this to be encountered. We've implemented a class called ObjectValue that allows us to have nested properties (required by the model we're working with) which results in a query like this being valid:
g.V().hasLabel("myLabel").values().values()
Again, this is a very theoretical example, and it would be unusual to call values twice in succession with no parameters, but I did this in a unit test which is what triggered the behaviour I described above....
So again to reiterate, this is a very niche situation which no one else is likely to hit but I just thought it worth bring to attention, given I don't know where else this logic may be used...Solution:Jump to solution
On the other hand, @dbns97_61020 's issue is that we have the exact same
PropertiesStep under the same traversal.
I am not sure if we need to improve that part, a user might need to specify the Step they want by its index, or use == and compare by reference (you need the reference of the exact object in advance though). You may also rely on Step ID to identify some Step in such case as well....3 Replies
Hi @dbns97_61020
looks like it's known issue https://issues.apache.org/jira/browse/TINKERPOP-2423
It is a bit different issue, the JIRA ticket is about having redundant parameters will have a conflict because it relies on
XOR to compute hashCode. I am working on a fix.Solution
On the other hand, @dbns97_61020 's issue is that we have the exact same
PropertiesStep under the same traversal.
I am not sure if we need to improve that part, a user might need to specify the Step they want by its index, or use == and compare by reference (you need the reference of the exact object in advance though). You may also rely on Step ID to identify some Step in such case as well.