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? >
