How to dynamically add custom Steps at runtime?
I am maintaining a graph engine service that provides different products. I have found that some complex scenarios cannot get query results through native Steps. Special business logic operations are required to implement custom special syntax through business code. The current custom syntax is done through @GremlinDsl, which is generated at compile time and the code is written in my own service. I hope that this special syntax can be defined by the product itself and pushed to the specified directory and loaded at service runtime. Can the TinkerPop framework do this? How can it be done? What is the specific implementation method?
Solution:Jump to solution
You can use Groovy for all manner of trickery (AST manipulation, basic metaprogramming APIs, etc), but I'd take care with depending on it given the security risks associated with it. TinkerPop has been slowly moving away from it, first with bytecode based requests and more currently with the Gremlin ANTLR grammar. There is a general consensus that the latter will ultimately replace groovy/bytecode going forward into the future. I'm not sure if any of that impacts your decisions on how to maintai...
4 Replies
for providers something similar can be done by adding a service and using it with
call step.
Examples of custom services in TinkerPop: TinkerTextSearchFactory and TinkerDegreeCentralityFactory.
Doc for call step: https://tinkerpop.apache.org/docs/current/reference/#call-stepThanks for your reply! I checked that the call step was added in version 3.6, and the service supporting version is 3.5. I seem to have found a way to achieve a similar effect through Groovy AST parsing;
For example, a downstream product pushes a configuration file to a platform service. The file name is xx.groovy. When calling the platform service interface, pass in Gremlin containing xx(), and replace xx with the code of the push file through AST;
Solution
You can use Groovy for all manner of trickery (AST manipulation, basic metaprogramming APIs, etc), but I'd take care with depending on it given the security risks associated with it. TinkerPop has been slowly moving away from it, first with bytecode based requests and more currently with the Gremlin ANTLR grammar. There is a general consensus that the latter will ultimately replace groovy/bytecode going forward into the future. I'm not sure if any of that impacts your decisions on how to maintain your service using 3.5.x but I thought it was important to share.
Thank you for your suggestion. The current version is based on the company's software selection and will be updated every year. The new version will be upgraded in the future. When there is a better and safer way, we will switch;