I assume you're targeting the master branch with this change. If so, then I don't think there is a problem with going to a newer version.
Out of curiosity, you mentioned this update as a "need" - is there something specific in the newer version that is required for the implementation? On Tue, Jan 20, 2026 at 4:47 AM Andrii Lomakin via dev < [email protected]> wrote: > Good day, TP team. > To implement this feature, we need to update ANTLR to the latest version. > Do you have any objections ? > If not, we will provide PR soon. > > On Mon, Jan 19, 2026 at 4:39 PM Andrii Lomakin < > [email protected]> > wrote: > > > 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 > > > > > -- > Andrii Lomakin > YouTrackDB development lead >
