> I'm not sure I'm following exactly what you're envisioning with the conditional filtering and support of GQL functions (I may need some examples), but those are the details we should align through the creation of the GQL-Gremlin specification.
+1 to building more clarity with examples on the way to creating a specification that we can find consensus on. i added a first example around empty/traverser semantics in the other thread related to this: https://lists.apache.org/thread/9gzz1vh2hl72svo65n03r8hgzqgwtbhl On Wed, Nov 19, 2025 at 12:57 PM Cole Greer <[email protected]> wrote: > Hi Andrii, > > Sorry for my delay in joining this thread. > > Overall I agree with the process outline you've shared, with 1 and 2 being > the most critical to ensure complete alignment. > > Jumping on Stephen's point, I've generally envisioned this work to simply > allow for match patterns with a GQL-style path structure, and including > node/edge label and property filters. I think there is value in keeping > this as simple as possible in the initial design, as long as we aren't > blocking ourselves from iterating and extending the work once this gets in > the hands of users and we start receiving more feedback. > > I'm not sure I'm following exactly what you're envisioning with the > conditional filtering and support of GQL functions (I may need some > examples), but those are the details we should align through the creation > of the GQL-Gremlin specification. I'm still envisioning a very simple, > restricted subset of GQL for the initial version of this, however it's > unlikely I'll be opposed to any additions which A. Add a capability which > is otherwise missing (or inconvenient) in gremlin post-processing, and B. > Remain straightforward for providers to support. > > Thanks, > Cole > > On 2025/11/11 14:10:04 Andrii Lomakin wrote: > > Hi Stephen, > > > > To double-check, when I say 'filter step,' I meant specifically filtering > > in one of the paths of the match query. > > If we implement only filtering by node labels and relations, this > > functionality is unlikely to be easily reproduced by post-processing with > > Gremlin steps. > > > > Do you think that part can be omitted? > > > > > > On Tue, Nov 11, 2025 at 2:54 PM Stephen Mallette <[email protected]> > > wrote: > > > > > I'd agree with the idea that you do the implementation in TinkerPop and > > > then consume it in your implementation. It leaves the least chance for > > > divergence and "large" bodies of code developed outside of the > TinkerPop > > > Community that are then contributed might have to go through additional > > > steps beyond just a basic pull request to be merged given ASF > guidelines. > > > It's much easier all around if it's all developed here openly. I'm sure > > > core contributors will do their best to ensure that feedback is > provided > > > quickly when needed so that your work isn't slowed all that much when > > > building consensus. > > > > > > I'd also agree with the general plan you have described. As I'd thought > > > about this over the years, I don't think I'd envisioned a case where > all of > > > GQL would all be supported from the start and that it would take a long > > > time to get all of it (if TinkerPop needed to support all of it ever). > The > > > critical part in my mind is the subset for general pattern > > > matching/filtering, so step 1a makes sense to me. Regarding step 3, > > > TinkerPop could facilitate this by creating a feature branch for this > so > > > that all PRs related to this work could have a space to target. > Regarding > > > step 4, i think we'd mostly intended for this change to land in 4.0.0, > > > though I don't think it's been discussed. > > > > > > > > > > > > > > > > > > On Tue, Nov 11, 2025 at 5:32 AM Andrii Lomakin > > > <[email protected]> wrote: > > > > > > > Good day. > > > > > > > > I would like to share with you our ideas regarding the > implementation of > > > > the match step and GQL queries. > > > > > > > > Initially, we thought of implementing our own version of the match > step > > > > first. > > > > However, such an approach leads to an increased risk of greater > > > > fragmentation within the graph community. Therefore, we decided to > > > > contribute to the implementation of match to the TinkerPop project > and > > > > subsequently create our own version based on this implementation. > > > > > > > > That obviously implies coordination with the core TinkerPop team. > > > > > > > > We believe our implementation should be divided into the following > steps. > > > > 1. Initially, we create a specification of GQL supported by Gremlin, > as > > > > that will be only a subset of the whole GQL language. Here is a > trick: if > > > > we create and implement the specification as a whole, it may take > > > > figuratively years for us to provide the final version. > > > > Instead, we want to split it into several parts. > > > > Currently, we see three parts that will be implemented separately > through > > > > iterations: a. Filtering by node label and relations. b. Addition of > > > > conditional filtering. c. support of GQL functions. The specification > > > will > > > > be created as a whole but will be split by iterations. > > > > After the final iteration, a new specification will be created that > > > merges > > > > all the parts together in a more understandable manner. > > > > 2. Then we create a semantic specification of the match step as was > > > > suggested by Stephen Mallette > > > > > > > > > > > > https://github.com/apache/tinkerpop/blob/master/docs/src/dev/provider/gremlin-semantics.asciidoc > > > > . > > > > 3. We create a public fork/branch of the TinkerPop project, invite > > > > everybody who wants to help, and start our implementation by > iterations. > > > > 4. Once it is ready, we will incorporate it into our project > (YouTrackDB) > > > > and provide a version tailored for our database internals. > > > > > > > > WDYT? > > > > > > > > > >
