You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Andrii Lomakin <an...@jetbrains.com.INVALID> on 2025/11/05 16:14:57 UTC
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.
Re: [DISCUSS] 3.9.x release line was: Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Andrii Lomakin via dev <de...@tinkerpop.apache.org>.
Good day, Stephen.
If it will be possible to:
1. Update library visions.
2. Add JDK 25 support (I have seen a PR there, and we also work on JDK 25,
and what I see is the issue only in Groovy).
That will unlock us to provide our contributions if I got everything
correctly.
On Wed, Jan 21, 2026 at 2:14 PM Stephen Mallette <sp...@gmail.com>
wrote:
> Hi Andrii - now that 3.8.x is out, I think most new features will be
> targeted for 4.x with particular focus on addressing the gaps that
> currently exist there (like transactions). It's not clear how long that
> will take as of yet. While most effort will be on 4.x, if you think that
> you have more contributions like this change with call/antlr, I think that
> we could talk about doing a 3.9.x if that is helpful to you.
>
> Roughly speaking, I think 3.9.x changes would merge to 4.x and would need
> to maintain Gremlin semantics established in 3.8.x and avoid any breaking
> changes to drivers. Additive features would be less of an issue (like
> call/antlr) but like all features, we'd take each one on a case by case
> basis to decide what release line they are best for.
>
> Do you feel like you would like a 3.9.0?
>
> Also, happy to hear from other contributors on this topic. We hadn't
> planned a 3.9.0, so please consider this an open discussion.
>
>
>
> On Wed, Jan 21, 2026 at 2:14 AM Andrii Lomakin <
> andrey.lomakin@jetbrains.com> wrote:
>
>> 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 <
>> andrey.lomakin@jetbrains.com> 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 <sp...@gmail.com>
>>> 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 <
>>>> dev@tinkerpop.apache.org> 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 <
>>>>> andrey.lomakin@jetbrains.com>
>>>>> 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 <
>>>>> andrii0lomakin@gmail.com>
>>>>> > 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 <ke...@gmail.com> 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 <
>>>>> spmallette@gmail.com>
>>>>> >> > 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 <ke...@gmail.com>
>>>>> 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
>>>>> >> > > > <an...@jetbrains.com.invalid> 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, <ke...@gmail.com>
>>>>> 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
>>>>> >> > > > > > <an...@jetbrains.com.invalid> 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 <
>>>>> kenhuoss@gmail.com>
>>>>> >> > > 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 <
>>>>> >> > > > > > > andrii0lomakin@gmail.com>
>>>>> >> > > > > > > > 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 <
>>>>> >> > > > > > > andrii0lomakin@gmail.com
>>>>> >> > > > > > > > >
>>>>> >> > > > > > > > > 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 <
>>>>> >> kenhuoss@gmail.com
>>>>> >> > >
>>>>> >> > > > > 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
>>>>> >> > > > > > > > > > > <An...@improving.com.invalid> 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 <
>>>>> andrey.lomakin@jetbrains.com
>>>>> >> > > > .INVALID>
>>>>> >> > > > > > > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM
>>>>> >> > > > > > > > > > > > To: dev@tinkerpop.apache.org <
>>>>> >> dev@tinkerpop.apache.org
>>>>> >> > >
>>>>> >> > > > > > > > > > > > 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
>>
>
--
Andrii Lomakin
YouTrackDB development lead
[DISCUSS] 3.9.x release line was: Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Stephen Mallette <sp...@gmail.com>.
Hi Andrii - now that 3.8.x is out, I think most new features will be
targeted for 4.x with particular focus on addressing the gaps that
currently exist there (like transactions). It's not clear how long that
will take as of yet. While most effort will be on 4.x, if you think that
you have more contributions like this change with call/antlr, I think that
we could talk about doing a 3.9.x if that is helpful to you.
Roughly speaking, I think 3.9.x changes would merge to 4.x and would need
to maintain Gremlin semantics established in 3.8.x and avoid any breaking
changes to drivers. Additive features would be less of an issue (like
call/antlr) but like all features, we'd take each one on a case by case
basis to decide what release line they are best for.
Do you feel like you would like a 3.9.0?
Also, happy to hear from other contributors on this topic. We hadn't
planned a 3.9.0, so please consider this an open discussion.
On Wed, Jan 21, 2026 at 2:14 AM Andrii Lomakin <an...@jetbrains.com>
wrote:
> 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 <
> andrey.lomakin@jetbrains.com> 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 <sp...@gmail.com>
>> 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 <
>>> dev@tinkerpop.apache.org> 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 <
>>>> andrey.lomakin@jetbrains.com>
>>>> 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 <
>>>> andrii0lomakin@gmail.com>
>>>> > 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 <ke...@gmail.com> 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 <
>>>> spmallette@gmail.com>
>>>> >> > 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 <ke...@gmail.com>
>>>> 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
>>>> >> > > > <an...@jetbrains.com.invalid> 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, <ke...@gmail.com>
>>>> 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
>>>> >> > > > > > <an...@jetbrains.com.invalid> 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 <
>>>> kenhuoss@gmail.com>
>>>> >> > > 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 <
>>>> >> > > > > > > andrii0lomakin@gmail.com>
>>>> >> > > > > > > > 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 <
>>>> >> > > > > > > andrii0lomakin@gmail.com
>>>> >> > > > > > > > >
>>>> >> > > > > > > > > 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 <
>>>> >> kenhuoss@gmail.com
>>>> >> > >
>>>> >> > > > > 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
>>>> >> > > > > > > > > > > <An...@improving.com.invalid> 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 <
>>>> andrey.lomakin@jetbrains.com
>>>> >> > > > .INVALID>
>>>> >> > > > > > > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM
>>>> >> > > > > > > > > > > > To: dev@tinkerpop.apache.org <
>>>> >> dev@tinkerpop.apache.org
>>>> >> > >
>>>> >> > > > > > > > > > > > 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
>
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Andrii Lomakin via dev <de...@tinkerpop.apache.org>.
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 <an...@jetbrains.com>
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 <sp...@gmail.com>
> 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 <
>> dev@tinkerpop.apache.org> 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 <
>>> andrey.lomakin@jetbrains.com>
>>> 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 <
>>> andrii0lomakin@gmail.com>
>>> > 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 <ke...@gmail.com> 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 <
>>> spmallette@gmail.com>
>>> >> > 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 <ke...@gmail.com>
>>> 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
>>> >> > > > <an...@jetbrains.com.invalid> 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, <ke...@gmail.com>
>>> 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
>>> >> > > > > > <an...@jetbrains.com.invalid> 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 <
>>> kenhuoss@gmail.com>
>>> >> > > 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 <
>>> >> > > > > > > andrii0lomakin@gmail.com>
>>> >> > > > > > > > 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 <
>>> >> > > > > > > andrii0lomakin@gmail.com
>>> >> > > > > > > > >
>>> >> > > > > > > > > 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 <
>>> >> kenhuoss@gmail.com
>>> >> > >
>>> >> > > > > 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
>>> >> > > > > > > > > > > <An...@improving.com.invalid> 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 <
>>> andrey.lomakin@jetbrains.com
>>> >> > > > .INVALID>
>>> >> > > > > > > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM
>>> >> > > > > > > > > > > > To: dev@tinkerpop.apache.org <
>>> >> dev@tinkerpop.apache.org
>>> >> > >
>>> >> > > > > > > > > > > > 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
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Andrii Lomakin via dev <de...@tinkerpop.apache.org>.
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 <sp...@gmail.com>
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 <
> dev@tinkerpop.apache.org> 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 <
>> andrey.lomakin@jetbrains.com>
>> 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 <
>> andrii0lomakin@gmail.com>
>> > 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 <ke...@gmail.com> 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 <
>> spmallette@gmail.com>
>> >> > 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 <ke...@gmail.com>
>> 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
>> >> > > > <an...@jetbrains.com.invalid> 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, <ke...@gmail.com> 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
>> >> > > > > > <an...@jetbrains.com.invalid> 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 <
>> kenhuoss@gmail.com>
>> >> > > 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 <
>> >> > > > > > > andrii0lomakin@gmail.com>
>> >> > > > > > > > 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 <
>> >> > > > > > > andrii0lomakin@gmail.com
>> >> > > > > > > > >
>> >> > > > > > > > > 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 <
>> >> kenhuoss@gmail.com
>> >> > >
>> >> > > > > 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
>> >> > > > > > > > > > > <An...@improving.com.invalid> 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 <
>> andrey.lomakin@jetbrains.com
>> >> > > > .INVALID>
>> >> > > > > > > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM
>> >> > > > > > > > > > > > To: dev@tinkerpop.apache.org <
>> >> dev@tinkerpop.apache.org
>> >> > >
>> >> > > > > > > > > > > > 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
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Stephen Mallette <sp...@gmail.com>.
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 <
dev@tinkerpop.apache.org> 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 <
> andrey.lomakin@jetbrains.com>
> 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 <andrii0lomakin@gmail.com
> >
> > 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 <ke...@gmail.com> 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 <
> spmallette@gmail.com>
> >> > 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 <ke...@gmail.com> 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
> >> > > > <an...@jetbrains.com.invalid> 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, <ke...@gmail.com> 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
> >> > > > > > <an...@jetbrains.com.invalid> 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 <kenhuoss@gmail.com
> >
> >> > > 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 <
> >> > > > > > > andrii0lomakin@gmail.com>
> >> > > > > > > > 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 <
> >> > > > > > > andrii0lomakin@gmail.com
> >> > > > > > > > >
> >> > > > > > > > > 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 <
> >> kenhuoss@gmail.com
> >> > >
> >> > > > > 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
> >> > > > > > > > > > > <An...@improving.com.invalid> 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 <
> andrey.lomakin@jetbrains.com
> >> > > > .INVALID>
> >> > > > > > > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM
> >> > > > > > > > > > > > To: dev@tinkerpop.apache.org <
> >> dev@tinkerpop.apache.org
> >> > >
> >> > > > > > > > > > > > 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
>
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Andrii Lomakin via dev <de...@tinkerpop.apache.org>.
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 <an...@jetbrains.com>
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 <an...@gmail.com>
> 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 <ke...@gmail.com> 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 <sp...@gmail.com>
>> > 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 <ke...@gmail.com> 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
>> > > > <an...@jetbrains.com.invalid> 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, <ke...@gmail.com> 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
>> > > > > > <an...@jetbrains.com.invalid> 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 <ke...@gmail.com>
>> > > 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 <
>> > > > > > > andrii0lomakin@gmail.com>
>> > > > > > > > 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 <
>> > > > > > > andrii0lomakin@gmail.com
>> > > > > > > > >
>> > > > > > > > > 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 <
>> kenhuoss@gmail.com
>> > >
>> > > > > 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
>> > > > > > > > > > > <An...@improving.com.invalid> 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 <andrey.lomakin@jetbrains.com
>> > > > .INVALID>
>> > > > > > > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM
>> > > > > > > > > > > > To: dev@tinkerpop.apache.org <
>> dev@tinkerpop.apache.org
>> > >
>> > > > > > > > > > > > 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
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Andrii Lomakin via dev <de...@tinkerpop.apache.org>.
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 <an...@gmail.com>
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 <ke...@gmail.com> 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 <sp...@gmail.com>
> > 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 <ke...@gmail.com> 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
> > > > <an...@jetbrains.com.invalid> 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, <ke...@gmail.com> 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
> > > > > > <an...@jetbrains.com.invalid> 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 <ke...@gmail.com>
> > > 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 <
> > > > > > > andrii0lomakin@gmail.com>
> > > > > > > > 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 <
> > > > > > > andrii0lomakin@gmail.com
> > > > > > > > >
> > > > > > > > > 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 <
> kenhuoss@gmail.com
> > >
> > > > > 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
> > > > > > > > > > > <An...@improving.com.invalid> 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 <andrey.lomakin@jetbrains.com
> > > > .INVALID>
> > > > > > > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM
> > > > > > > > > > > > To: dev@tinkerpop.apache.org <
> dev@tinkerpop.apache.org
> > >
> > > > > > > > > > > > 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
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Andrii Lomakin <an...@gmail.com>.
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 <ke...@gmail.com> 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 <sp...@gmail.com>
> 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 <ke...@gmail.com> 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
> > > <an...@jetbrains.com.invalid> 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, <ke...@gmail.com> 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
> > > > > <an...@jetbrains.com.invalid> 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 <ke...@gmail.com>
> > 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 <
> > > > > > andrii0lomakin@gmail.com>
> > > > > > > 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 <
> > > > > > andrii0lomakin@gmail.com
> > > > > > > >
> > > > > > > > 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 <kenhuoss@gmail.com
> >
> > > > 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
> > > > > > > > > > <An...@improving.com.invalid> 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 <andrey.lomakin@jetbrains.com
> > > .INVALID>
> > > > > > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM
> > > > > > > > > > > To: dev@tinkerpop.apache.org <dev@tinkerpop.apache.org
> >
> > > > > > > > > > > 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.
> > > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Ken Hu <ke...@gmail.com>.
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 <sp...@gmail.com>
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 <ke...@gmail.com> 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
> > <an...@jetbrains.com.invalid> 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, <ke...@gmail.com> 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
> > > > <an...@jetbrains.com.invalid> 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 <ke...@gmail.com>
> 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 <
> > > > > andrii0lomakin@gmail.com>
> > > > > > 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 <
> > > > > andrii0lomakin@gmail.com
> > > > > > >
> > > > > > > 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 <ke...@gmail.com>
> > > 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
> > > > > > > > > <An...@improving.com.invalid> 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 <andrey.lomakin@jetbrains.com
> > .INVALID>
> > > > > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM
> > > > > > > > > > To: dev@tinkerpop.apache.org <de...@tinkerpop.apache.org>
> > > > > > > > > > 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.
> > > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Stephen Mallette <sp...@gmail.com>.
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 <ke...@gmail.com> 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
> <an...@jetbrains.com.invalid> 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, <ke...@gmail.com> 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
> > > <an...@jetbrains.com.invalid> 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 <ke...@gmail.com> 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 <
> > > > andrii0lomakin@gmail.com>
> > > > > 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 <
> > > > andrii0lomakin@gmail.com
> > > > > >
> > > > > > 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 <ke...@gmail.com>
> > 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
> > > > > > > > <An...@improving.com.invalid> 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 <andrey.lomakin@jetbrains.com
> .INVALID>
> > > > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM
> > > > > > > > > To: dev@tinkerpop.apache.org <de...@tinkerpop.apache.org>
> > > > > > > > > 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.
> > > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Ken Hu <ke...@gmail.com>.
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
<an...@jetbrains.com.invalid> 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, <ke...@gmail.com> 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
> > <an...@jetbrains.com.invalid> 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 <ke...@gmail.com> 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 <
> > > andrii0lomakin@gmail.com>
> > > > 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 <
> > > andrii0lomakin@gmail.com
> > > > >
> > > > > 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 <ke...@gmail.com>
> 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
> > > > > > > <An...@improving.com.invalid> 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 <an...@jetbrains.com.INVALID>
> > > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM
> > > > > > > > To: dev@tinkerpop.apache.org <de...@tinkerpop.apache.org>
> > > > > > > > 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.
> > > > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Andrii Lomakin <an...@jetbrains.com.INVALID>.
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, <ke...@gmail.com> 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
> <an...@jetbrains.com.invalid> 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 <ke...@gmail.com> 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 <
> > andrii0lomakin@gmail.com>
> > > 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 <
> > andrii0lomakin@gmail.com
> > > >
> > > > 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 <ke...@gmail.com> 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
> > > > > > <An...@improving.com.invalid> 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 <an...@jetbrains.com.INVALID>
> > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM
> > > > > > > To: dev@tinkerpop.apache.org <de...@tinkerpop.apache.org>
> > > > > > > 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.
> > > > > > >
> > > >
> > >
> >
>
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Ken Hu <ke...@gmail.com>.
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
<an...@jetbrains.com.invalid> 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 <ke...@gmail.com> 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 <
> andrii0lomakin@gmail.com>
> > 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 <
> andrii0lomakin@gmail.com
> > >
> > > 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 <ke...@gmail.com> 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
> > > > > <An...@improving.com.invalid> 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 <an...@jetbrains.com.INVALID>
> > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM
> > > > > > To: dev@tinkerpop.apache.org <de...@tinkerpop.apache.org>
> > > > > > 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.
> > > > > >
> > >
> >
>
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Andrii Lomakin <an...@jetbrains.com.INVALID>.
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 <ke...@gmail.com> 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 <an...@gmail.com>
> 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 <andrii0lomakin@gmail.com
> >
> > 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 <ke...@gmail.com> 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
> > > > <An...@improving.com.invalid> 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 <an...@jetbrains.com.INVALID>
> > > > > Date: Wednesday, November 5, 2025 at 8:15 AM
> > > > > To: dev@tinkerpop.apache.org <de...@tinkerpop.apache.org>
> > > > > 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.
> > > > >
> >
>
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Ken Hu <ke...@gmail.com>.
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 <an...@gmail.com>
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 <an...@gmail.com>
> 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 <ke...@gmail.com> 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
> > > <An...@improving.com.invalid> 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 <an...@jetbrains.com.INVALID>
> > > > Date: Wednesday, November 5, 2025 at 8:15 AM
> > > > To: dev@tinkerpop.apache.org <de...@tinkerpop.apache.org>
> > > > 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.
> > > >
>
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Andrii Lomakin <an...@gmail.com>.
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 <an...@gmail.com> 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 <ke...@gmail.com> 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
> > <An...@improving.com.invalid> 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 <an...@jetbrains.com.INVALID>
> > > Date: Wednesday, November 5, 2025 at 8:15 AM
> > > To: dev@tinkerpop.apache.org <de...@tinkerpop.apache.org>
> > > 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.
> > >
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Andrii Lomakin <an...@gmail.com>.
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 <ke...@gmail.com> 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
> <An...@improving.com.invalid> 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 <an...@jetbrains.com.INVALID>
> > Date: Wednesday, November 5, 2025 at 8:15 AM
> > To: dev@tinkerpop.apache.org <de...@tinkerpop.apache.org>
> > 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.
> >
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Ken Hu <ke...@gmail.com>.
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
<An...@improving.com.invalid> 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 <an...@jetbrains.com.INVALID>
> Date: Wednesday, November 5, 2025 at 8:15 AM
> To: dev@tinkerpop.apache.org <de...@tinkerpop.apache.org>
> 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.
>
Re: Proposal: Intorduction of equalence between call(serviceName, args:List) and method call in scripts
Posted by Andrea Child <An...@improving.com.INVALID>.
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 <an...@jetbrains.com.INVALID>
Date: Wednesday, November 5, 2025 at 8:15 AM
To: dev@tinkerpop.apache.org <de...@tinkerpop.apache.org>
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.