Good day. I suppose I need to add more context. We cannot use 4.0 if it will be released with the current feature set (for reasons I mentioned in other topics), so all development we do is on top of the 3.8 release branch.
I think it would be beneficial to backport our changes to 3.8 if possible, but given the release policy situation, I am not sure it is. Would be glad if the TinkerPop team could share any ideas with us. Also, I invite anyone to join our Zulip chat to participate in discussions about our early-stage implementation of GQL. We, of course, will contact you once it is ready to refine the spec of the match step anyway. On Tue, Jan 20, 2026 at 4:11 PM Andrii Lomakin <[email protected]> wrote: > 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 > -- Andrii Lomakin YouTrackDB development lead
