Creating a customer serializer Io Registry in Java
Hey folks,
I've got a somewhat unusual use case I'd like to bring to G.V(). Some users have customer serializers configured on their servers and I'd like to find a way to allow them to configure G.V() using those custom serializers. My initial thought was to create a "custom" IoRegistry that loads those classes via reflection based on user input information (e.g. jar path and class name). Would that be the correct way to load custom serializers into a client Java codebase?
I've been looking at some custom serializer examples but they focus mostly on the server side of things, not so much the client, gremlin-driver part of it
Solution:Jump to solution
cool, i think that clarifies everything, im clear on the approach to take moving forward for G.V(), the best solution is to simply allow onboarding a user's custom IO registry via a packaged jar, likely the same one they would drop under lib for their JG install
9 Replies
We do use custom serializers on the server side (to be able to pass data from JanusGraph to TinkerGraph and back), but I never played with custom serializers on the client driver side. I believe it should be possible like you described because we do use custom serializers for some type (like Geoshape for example just fine).
If you find a proper way to do that, please share it here (or directly into the documentation) so that we can document it once and for all.
Otherwise I will check this later and document it.
Cool, ill keep you posted - ill snatch some custom serialisers from the repo's tests and try going for a multi ioregistry load setup on the driver, on for janusgraph and one for custom types if configured in g.v. I'll wrestle a bit with java reflection to figure out what the right way of prompting those but im assuming file path to jar or perhaps class file
@porunov got a little follow up question or two here as I'm trying to get this setup for testing. I've snatched some custom classes/serializers from https://github.com/pluradj/janusgraph-attribute-serializer/tree/master (I know it's deprecated but it's still workable by the looks of it).
I've configured my JG instance with a couple custom attribute types, but when attempting to add a vertex with one of those custom types, I'm getting the following error:
, which is thrown server side. Would that indicate a misconfiguration on my end or is there some other config im missing here?
GitHub
GitHub - pluradj/janusgraph-attribute-serializer: Example custom at...
Example custom attribute serialization for JanusGraph database - GitHub - pluradj/janusgraph-attribute-serializer: Example custom attribute serialization for JanusGraph database
My second question is around customer serializers - everything in the docs mentions the use of AttributeSerializer as the super class to use but I notice IoRegistry class registration expects a serializer class inheriting an implementation specific to the serializer in use (GraphSON, Gryo, GraphBinary...). Is there an additional custom serializer matching the serializer type in use?
I am not sure about
AttributeSerializer but I think nowadays you should use GraphSON or GraphBinary if you want to write custom serializers.
The server can support different formats like GraphSON and GraphBinary, but the the client chooses one of those types. This is shown here in the TinkerPop docs for Java for example: https://tinkerpop.apache.org/docs/current/reference/#gremlin-java-serialization
The server then needs to support the custom type with a custom serializer at least for the format that you want to use on the client sideHere you can find an example for a custom GraphBinary serializer in Java: https://github.com/apache/tinkerpop/blob/master/gremlin-util/src/test/java/org/apache/tinkerpop/gremlin/util/ser/binary/types/sample/SamplePersonSerializer.java
GitHub
tinkerpop/gremlin-util/src/test/java/org/apache/tinkerpop/gremlin/u...
Apache TinkerPop - a graph computing framework. Contribute to apache/tinkerpop development by creating an account on GitHub.
thanks, that confirms my understanding - i think i got misled by the custom attribute serialization aspect on JanusGraph itself, as i was aware of the IoRegistry based implementations within Tinkerpop. Is it fair to say that the AttributeSerializer's purpose, specific to JanusGraph, is only to handle writing back to the storage backend, hence why it is JG specific?
I'm also not that firm in that part of the code base, but yes, it also looks to me like this is only for serializing data for the backend
Solution
cool, i think that clarifies everything, im clear on the approach to take moving forward for G.V(), the best solution is to simply allow onboarding a user's custom IO registry via a packaged jar, likely the same one they would drop under lib for their JG install