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
