4 replies

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

apply

apply

method of the strategy I was getting the index of the

PropertiesStep

PropertiesStep

instances using the

indexOf

indexOf

method:

traversal.getSteps().indexOf(step)

traversal.getSteps().indexOf(step)

This same logic is used by the built in

ReferenceElementStrategy

ReferenceElementStrategy

(maybe others but I haven't checked).

The problem is that

indexOf

indexOf

was not always returning the correct index. After some digging I found that

PropertiesStep.hashcode()

PropertiesStep.hashcode()

does not necessarily return a unique value.
In my case, there were two instances of

PropertiesStep

PropertiesStep

in the traversal, both of which were returning the same value from

PropertiesStep.hashcode()

PropertiesStep.hashcode()

.

I've managed to avoid using

indexOf

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

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()

g.V().hasLabel("myLabel").values().values()

Again, this is a very theoretical example, and it would be unusual to call

values

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

On the other hand, @dbns97_61020 's issue is that we have the exact same

PropertiesStep

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.

Jump to solution

Apache TinkerPop•3y ago•

4 replies

dbns97

PropertiesStep.hashcode() not always unique

apply

apply

method of the strategy I was getting the index of the

PropertiesStep

PropertiesStep

instances using the

indexOf

indexOf

method:

traversal.getSteps().indexOf(step)

traversal.getSteps().indexOf(step)

This same logic is used by the built in

ReferenceElementStrategy

ReferenceElementStrategy

(maybe others but I haven't checked).

The problem is that

indexOf

indexOf

was not always returning the correct index. After some digging I found that

PropertiesStep.hashcode()

PropertiesStep.hashcode()

does not necessarily return a unique value.
In my case, there were two instances of

PropertiesStep

PropertiesStep

in the traversal, both of which were returning the same value from

PropertiesStep.hashcode()

PropertiesStep.hashcode()

.

I've managed to avoid using

indexOf

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

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()

g.V().hasLabel("myLabel").values().values()

Again, this is a very theoretical example, and it would be unusual to call

values

values

Solution

On the other hand, @dbns97_61020 's issue is that we have the exact same

PropertiesStep

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.

Jump to solution

PropertiesStep.hashcode() not always unique

PropertiesStep.hashcode() not always unique

Similar Threads

Similar Threads

Similar Threads