Good day. As part of our efforts to implement GQL, we started working on this issue: https://youtrack.jetbrains.com/issue/YTDB-505/Implement-the-ability-to-convert-non-standard-method-calls-into-the-registered-service-calls . Sandra will provide PR once it is ready.
On Fri, Nov 21, 2025 at 1:52 PM Andrii Lomakin <[email protected]> wrote: > Good day, > > Following up on Ken's point about the discrepancy between scripts and > traversals, I have an alternative idea that could resolve this issue, in > addition to the proposal I mentioned in the other thread. > > The proposal is to introduce a mechanism that allows a user to create a > part of a graph traversal in script form, such as: > `g.gScript("V(id).hasName()")` > > The responsibility for handling this script would then fall to the GLV, > which would have two primary options: > > 1. Pass the script string to the server for parsing. > 2. Convert the script to local steps before passing the steps to the server > (my preferred approach). > > For the latter, a more advanced option could be available for vendors > working on Java: they could use a ClassLoader to dynamically download the > vendor’s JAR from Gremlin Server into the client’s classpath. If this > approach were adopted, the ClassLoading mechanism would need to become a > formal part of the Gremlin Server protocol, as the vendor does not control > the client at this stage. > > This dynamic approach could also address issues related to custom > serializers, though it would likely only be applicable to Java and other > dynamic languages, and not to languages like Go. However, for drivers such > as .NET, JavaScript, and Python, a similar level of abstraction could > potentially be implemented within the protocol to achieve the same result. > > Best regards, > > Andrii Lomakin > YouTrackDB development lead. > > On Thu, Nov 20, 2025 at 7:09 PM Ken Hu <[email protected]> wrote: > > > I think the initial challenge that I pointed out still exists, which is, > > scripts and traversals won't have the same capabilities out-of-the-box. > > Again, I'm in favor of this proposal and would like to see it > implemented. > > All I'm trying to say is, can we also come up with an equivalent proposal > > for remote traversals. > > > > On Thu, Nov 20, 2025 at 5:18 AM Stephen Mallette <[email protected]> > > wrote: > > > > > I think Ken provides a good point to consider about external > > dependencies. > > > Andrii, for further context, traditionally, we've found that users tend > > to > > > expect TinkerPop to just work with any provider. They want to download > a > > > driver in their programming language and get to work writing their > > > applications. What they have found is that in some cases it's not quite > > as > > > easy as that. For example, Ken alludes to the serializers where users > > often > > > learn in a very hard way that if they use JanusGraph they need to add > in > > a > > > customer serializer for certain operations to work. We've made it a > goal > > > for TinkerPop 4.x to not require TinkerPop drivers to have those kinds > of > > > dependencies that complicate the user experience. > > > > > > I think in this case, a DSL offers as a separate dependency by a > provider > > > doesn't exactly conflict with this goal because the DSL simply enhances > > the > > > experience the user has, but doesn't require it for standard TinkerPop > > > features to work. A user could even fallback to raw call() steps > without > > > using the DSL at all and still access the same functionality. The DSL > is > > > merely a (highly useful) convenience in this case. Ken, do you think > that > > > perspective helps align this idea to the goal of trying to keep things > > > working out-of-the-box? > > > > > > On Wed, Nov 19, 2025 at 12:25 PM Ken Hu <[email protected]> wrote: > > > > > > > That's not necessarily the case. If you think that there are users > that > > > > don't mind doing that then it is fine. I've just seen questions from > > > users > > > > in the past about how to make the GLV work with specific providers > > > because > > > > they didn't realize they needed additional dependencies and where to > > find > > > > those dependencies. I'm just wondering how and if it impacts user > > > > experience. > > > > > > > > On Wed, Nov 19, 2025 at 9:18 AM Andrii Lomakin > > > > <[email protected]> wrote: > > > > > > > > > Is my understanding correct that you don't support this change if > it > > > > > requires additional dependencies from vendor ? > > > > > > > > > > On Wed, 19 Nov 2025, 17:51 Ken Hu, <[email protected]> wrote: > > > > > > > > > > > I don't think this proposal requires custom serializers. I was > > trying > > > > to > > > > > > say that based on my understanding of this proposal, there may be > > an > > > > > issue > > > > > > that is similar to the one we see with custom serializers. That > > issue > > > > > > being, how is this custom provider DSL packaged with the GLV so > > that > > > > > users > > > > > > can gain access to those additional methods in remote traversals > > > > without > > > > > > needing to add an additional dependency from the provider itself? > > > > > > > > > > > > On Tue, Nov 18, 2025 at 10:46 PM Andrii Lomakin > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > Good day, Ken. > > > > > > > > > > > > > > Could you clarify why you think that this proposal requires > > custom > > > > > > > serializers? > > > > > > > > > > > > > > On Tue, Nov 18, 2025 at 11:39 PM Ken Hu <[email protected]> > > > wrote: > > > > > > > > > > > > > > > I guess I'm still not certain how this DSL would get packaged > > > with > > > > > the > > > > > > > > GLVs. One of the situations I'm trying to avoid is the one we > > > face > > > > > with > > > > > > > > custom type serialization. Providers with custom types > > generally > > > > need > > > > > > to > > > > > > > > package their serializers as a separate module which users of > > the > > > > GLV > > > > > > > will > > > > > > > > then add as a dependency. This creates confusion for users as > > > they > > > > > > aren't > > > > > > > > able to just use the GLV by itself. They need to grab an > > > additional > > > > > > > > dependency from their provider as well. It isn't always clear > > to > > > > them > > > > > > > that > > > > > > > > this is the case. > > > > > > > > > > > > > > > > On Fri, Nov 14, 2025 at 10:04 AM Andrii Lomakin < > > > > > > > [email protected]> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Hi Ken, > > > > > > > > > > > > > > > > > > To clarify, the functionality you mentioned regarding > remote > > > > > > Traversal > > > > > > > > > from a GLV is already fully supported by TinkerPop. > > > > > > > > > > > > > > > > > > While there are some current issues with the DSL processor, > > > they > > > > > are > > > > > > > > > implementation details that we intend to resolve through > the > > > > > > > > > contribution of our version of an annotation processor, > which > > > > will > > > > > > not > > > > > > > > > require any changes to the TinkerPop documentation. > > > > > > > > > > > > > > > > > > For a concrete example of our implementation of DSL, please > > see > > > > the > > > > > > > > > following: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/JetBrains/youtrackdb/blob/develop/core/src/main/java/com/jetbrains/youtrackdb/api/gremlin/YTDBGraphTraversalDSL.java > > > > > > > > > ( > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/JetBrains/youtrackdb/blob/develop/core/src/main/java/com/jetbrains/youtrackdb/api/gremlin/YTDBGraphTraversalDSL.java > > > > > > > > > ) > > > > > > > > > > > > > > > > > > Andrii Lomakin, > > > > > > > > > YouTrackDB development lead. > > > > > > > > > > > > > > > > > > On Fri, Nov 14, 2025 at 6:59 PM Andrii Lomakin < > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Ken, > > > > > > > > > > > > > > > > > > > > The scenario you described regarding remote Traversal > from > > a > > > > GLV > > > > > is > > > > > > > > > > automatically handled. > > > > > > > > > > > > > > > > > > > > The GLV would provide code similar to the existing > > > > implementation > > > > > > we > > > > > > > > > > already have, which can be found here: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/JetBrains/youtrackdb/blob/develop/core/src/main/java/com/jetbrains/youtrackdb/api/gremlin/YTDBGraphTraversalSourceDSL.java#L95 > > > > > > > > > > > > > > > > > > > > Andrii Lomakin, > > > > > > > > > > YouTrackDB development lead. > > > > > > > > > > > > > > > > > > > > On Fri, Nov 14, 2025 at 6:40 PM Ken Hu < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > What does this mean if someone tries to send a remote > > > > Traversal > > > > > > > from > > > > > > > > a > > > > > > > > > GLV? > > > > > > > > > > > I'm guessing that is what makes "1. Providing DSL that > > does > > > > the > > > > > > > same > > > > > > > > > call" > > > > > > > > > > > necessary. I think that scripts and traversals need to > > have > > > > the > > > > > > > same > > > > > > > > > > > capabilities "out of the box" when using the GLVs. So > > > while I > > > > > > think > > > > > > > > > this is > > > > > > > > > > > a good idea, I would also like to see a proposal on > what > > > can > > > > be > > > > > > > done > > > > > > > > > for > > > > > > > > > > > remote Traversals. > > > > > > > > > > > > > > > > > > > > > > On Thu, Nov 6, 2025 at 9:47 AM Andrea Child > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi Andrii, > > > > > > > > > > > > > > > > > > > > > > > > I like your idea as it would improve readability of > > > > > traversals > > > > > > to > > > > > > > > be > > > > > > > > > able > > > > > > > > > > > > to reference the service directly in the grammar > > instead > > > of > > > > > via > > > > > > > the > > > > > > > > > call > > > > > > > > > > > > step. Looking forward to the contribution! > > > > > > > > > > > > > > > > > > > > > > > > Andrea > > > > > > > > > > > > > > > > > > > > > > > > From: Andrii Lomakin <[email protected] > > > > .INVALID> > > > > > > > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM > > > > > > > > > > > > To: [email protected] < > [email protected] > > > > > > > > > > > > > > > Subject: Proposal: Intorduction of equalence between > > > > > > > > > call(serviceName, > > > > > > > > > > > > args:List) and method call in scripts > > > > > > > > > > > > > > > > > > > > > > > > Good day, colleagues. > > > > > > > > > > > > > > > > > > > > > > > > I would like to propose an approach to enhancing the > > > > > > > extensibility > > > > > > > > > of the > > > > > > > > > > > > Gremlin script, which, although it does not solve all > > > > > problems, > > > > > > > > will > > > > > > > > > make > > > > > > > > > > > > many Gremlin extensions feel native. > > > > > > > > > > > > The Idea, as you may have already guessed from the > > title, > > > > is > > > > > > > > simple: > > > > > > > > > if a > > > > > > > > > > > > service is registered in TinkerPop to treat it as a > > > method > > > > > call > > > > > > > > with > > > > > > > > > > > > parameters, such as args: List<Object> as an > argument. > > > > > > > > > > > > > > > > > > > > > > > > So call like: g.schemClass("User") will be translated > > to > > > > > > > > > > > > g.call("schemaClass", "args" : ["User]) > > > > > > > > > > > > > > > > > > > > > > > > In such a case, providers will extend Gremlin > twofold: > > > > > > > > > > > > 1. Providing DSL that does the same call. > > > > > > > > > > > > 2. Registering related service. > > > > > > > > > > > > > > > > > > > > > > > > If you agree with this proposal, I would be glad to > > > > > contribute > > > > > > > it, > > > > > > > > > as I > > > > > > > > > > > > mentioned, it does not solve all issues, such as the > > > usage > > > > of > > > > > > > > custom > > > > > > > > > > > > predicates, but I am under the impression that it can > > be > > > > > > extended > > > > > > > > to > > > > > > > > > that > > > > > > > > > > > > case too in the future. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Andrii Lomakin YouTrackDB development lead
