Details
-
Improvement
-
Status: Closed
-
Resolution: Done
-
None
-
None
Description
A problem we currently have with IO is that vendors may need to supply their own serializers for GraphSON on Kryo for custom classes. When using IO, users would have to know that they must configure their Reader/Writers with the vendor serializers for IO to work properly. This is also an issue for code in hadoop-gremlin where there is often code that uses the default configuration for the Reader/Writers which won't be able to serialize such custom classes. There are similar problems in the test suite which we solve by indirectly using GraphProvider to help configure the serializers properly per implementation.
We could solve this by adding an io method to Graph that returns an Io interface. The Io interface would be implemented by vendors to provide these core methods:
KryoReaderBuilder kryoReader() GraphSONReaderBuilder graphSONReader() GraphMLReaderBuilder graphMLReader() KryoWriterBuilder kryoWriter() GraphSONWriterBuilder graphSONWriter() GraphMLWriterBuilder graphMLWriter()
Each of these could have default implementations to return the vanilla implementation of the builders, but would have the option to set the all important custom serializer property so that when the user goes to use the builder it is all configured and ready to go.
This would also allow us to promote the save and load methods previously considered sugar to groovy into the java world, like:
g.io().saveGraphML('/tmp/g.xml') g.io().loadGraphML('/tmp/g.xml')
Right now, this won't even work properly in Groovy as sugar because the underlying reader/writer won't have the custom classes. What's nice is that we will still have a need for Groovy sugar with:
g.loadGraphML('/tmp/g.xml', incrementalLoading:true)
where we could pass build parameters as arguments.
What this might affect internally and other odds/ends to consider:
- These changes might mean some adjustments to the builders for IO classes as we might want to create a "system space" for registering serializers, that way users can register their own without conflict.
- The Io interface should probably expose methods to return the GraphSON/Kryo serialization modules, so that they can be used directly.
- Consider if this can help Gremlin Server in the sense that users have to configure extra serializers from vendors manually in the yaml file.