danielbodart commented on PR #3636:
URL: https://github.com/apache/tinkerpop/pull/3636#issuecomment-5626139650
Actually it's a super cool feature (well I think so), just by adding
support for this into the grammar we get federated graph calls.
I am building a clean room Gremlin server where each graph is fully
isolated. To query across graphs we have a federate step that runs a
sub-traversal on a sibling graph. The hard case is a mid-traversal federate:
every traverser on the local side carries a value that has to reach the
remote side, and we very much do not want a round trip per traverser.
So we batch them at the barrier. All the parents cross as one {parentId:
parentValue} map, a single bound parameter, and the remote side runs plain
Gremlin over it:
inject($map).unfold().group().by(Column.keys).by(<per-parent sub-traversal
over the entry value>)
That is the entire transport. group().by(Column.keys) gives us correlation
for free, and it stays correct when two different parents inject equal
values, because they are still two distinct keys. Results come back keyed
by parent, so we scatter them locally. The remote server needs no knowledge
whatsoever that it is being federated to. It is just a Gremlin query with a
bound parameter.
What the user writes is standard as well. An alias before the boundary, a
select after it:
g.V().hasLabel("person").values("name").as("e")
.call("federate", ["graph": "crew"])
.V().has("name", select("e"))
The one thing blocking it was inject() taking genericLiteralVarargs, so the
map could not arrive as a parameter at all. Hence the patch. Passing it as
a single bound map rather than per-parent arguments also matters more than
it looks: Our runtime caps a statement at 100 bound parameters, so we have
to make sure
The reason we're keen on it is where it goes next. Once the remote side can
return vertices and edges rather than only values and counts, federation is
complete. You can pull a subgraph from another graph and keep traversing
it, and since it is all standard Gremlin over HTTP, that works across
implementations, not just between two of ours.
On Fri, 4 Sept 2026 at 20:29, stephen mallette ***@***.***>
wrote:
> *spmallette* left a comment (apache/tinkerpop#3636)
> <https://github.com/apache/tinkerpop/pull/3636#issuecomment-5545488023>
>
> hello and thanks for the contribution. i was wondering if you had a
> specific need/use case for this feature that you could share or if it was
> just a point of syntax consistency that was driving it. any details you
> could share with us on that?
>
> —
> Reply to this email directly, view it on GitHub
>
<https://github.com/apache/tinkerpop/pull/3636?email_source=notifications&email_token=AAA6E2FLY5UF7WOWSN235BL5NMJZHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJUGU2DQOBQGIZ2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5545488023>,
> or unsubscribe
>
<https://github.com/notifications/unsubscribe-auth/AAA6E2DHULY7HKWINTLZ6DD5NMJZHAVCNFSNUABEKJSXA33TNF2G64TZHMZTANBUHE2DQMJ3JFZXG5LFHM2TGMJXGM3TGNZWG6QXMAQ>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
