MergeV uint32 properties inserted as long
Using a property map with OnCreate in MergeV exhibits different behavior if the property type is uint32 rather than int32.
If the property is uint32 then the property is serialized as a long.
If the property is int32, then it is serialized as integer.
I suspect that the type test does not cater for uintnn.
I can use int32 in this case, and I suppose long does not harm and probably needs to be long for int64, but is this an oversight?
5 Replies
The serialization system for Gremlin doesn't allow for unsigned numerics and roots itself in Java where we also don't have unsigned numerics, so an unint32 just folds into a long as that's the size the JVM would need to hold numbers larger than
Integer.MAX_VALUE. if you wanted to use uint32 you would have to know to convert the long returned from Gremlin manually. i don't know the .NET driver well, but I think that's the answer - @florianhockmann might have more to say on this topic.I think we don't support unsigned numerics in general in the GLVs as they aren't defined in the IO docs: https://tinkerpop.apache.org/docs/current/dev/io/#_data_type_formats
Not sure though to be honest how the individual GLVs behave when you give them an unsigned numeric type. I wouldn't be surprise if one GLV would through an exception whereas another would silently convert it to a signed numeric.
I think the question is about Gremlin-Go and not Gremlin.Net as the question has the
golang tag. Unfortunately, I don't know much about this GLV. Maybe@yangxia_ @colegreer or @valentyn_kahamlyk can say something about thisoops missed the golang tag, but i think the answer is essentially the same
Yes, for GremlinGo it was intentional as Stephen explained. Uint32 is serialized as a Java long because a Java integer would not be able to hold all uint32 values.
That's fine. Signed int works fine in this case, so will use that. I suppose long would actually be fine, but I suspect any Java based system will perform better with integer.