No, we based our changes on 3.8-dev. >Out of curiosity, you mentioned this update as a "need" - is there something specific in the newer version that is required for the implementation?
We had problems generating visitors for the updated grammar. On Tue, Jan 20, 2026 at 1:24 PM Stephen Mallette <[email protected]> wrote: > 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 >> > -- Andrii Lomakin YouTrackDB development lead
