As part of early feedback on mergeV/E, users have pointed out one major use
case that mergeE cannot support in its current form:
g.V()
.hasLabel("x").has("uid", "000001")
.outE("x")
.where(inV().hasLabel("x").has("uid", "000002"))
.fold()
.coalesce(
unfold(),
addE("y")
.from(V().hasLabel("x").has("uid", "000001"))
.to(V().hasLabel("x").has("uid", "000002"))
)
This query is not translatable into mergeE, because the Vertex IDs for the
from and to vertices are not known statically, but rather computed
dynamically at runtime. Late binding for the Direction.IN/OUT vertex IDs is
not currently supported by mergeE.
We can accomplish late binding on one the other vertex using upstream input
(g.V()....mergeE()) but this still leaves a gap for discovery of both sides
of the edge, except in cases of self-edges.
We propose breaking the current relationship between mergeE and its
upstream input (making it match the relationship with upstream input for
mergeV), and adding two new option values for mergeE where from and to
vertices can be discovered:
g.mergeE([T.label: "y", OUT: Merge.outV, IN: Merge:inV])
.option(Merge.outV, [T.label: "x", "uid": "000001"])
.option(Merge.inV, [T.label: "x", "uid": "000002"])
The Merge.outV/inV tokens will be used as option keys, and will also serve
as placeholders inside the mergeE argument maps for late binding of the
IN/OUT vertex IDs. Using Merge.outV (inV) for any value other than the
Direction.OUT
(IN) key in the merge argument maps will be disallowed.
We propose adding these new tokens and mergeE options to version 3.6.2.
We will assume a lazy consensus and proceed with these changes if there are
no objections by Wednesday 12/23/22 at 5pm ET.
