[DISCUSS] Proposal to add new options to mergeE

[Mike Personick <mi...@dayzero.io>]

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.

Re: [DISCUSS] Proposal to add new options to mergeE

[Kelvin Lawrence <gf...@yahoo.com.INVALID>]

Thanks for the detailed analysis Mike. It's great to get this kind of early feedback on new steps. Given my sense is that most databases have yet to implement support for mergeV and mergeV, if there are things we missed in the original design, that make the use of these steps easier, then it makes sense to make those changes ASAP.
Many users today struggle with the coalesce upsert patterns and struggle equally with map injection variations of the same tasks. We want the mergeV and mergE steps to be able to replace as many of those other query patterns as possible.
So, +1 from me on the changes you propose.
Cheers,Kelvin 

    On Friday, December 16, 2022 at 08:35:10 AM CST, Mike Personick <mi...@dayzero.io> wrote:  
 
 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.