Verify AddEdgeVCI Functionality

[zachkinstner]

It looks like the AddEdgeVCI function is adding null properties in cases where the property should simply be omitted. This may actually be a Fabric issue. Needs more investigation.

[zachkinstner]

Example from Fabric:

{
    "t": 33, 
    "r": [
        {
            "_properties": {
                "F_LoT": null, 
                "F_Df": null, 
                "F_LoX": null, 
                "F_LoY": null, 
                "F_LoZ": null, 
                "F_Fa": 2, 
                "F_No": null, 
                "F_EvD": null, 
                "F_Cr": 635138469813140946, 
                "N_FT": null, 
                "A_Cr": 635138387182929029, 
                "F_Co": null, 
                "F_DiR": null, 
                "F_DiT": null, 
                "F_Id": null, 
                "F_DiP": null, 
                "F_DeT": 7, 
                "F_VeU": null, 
                "F_VeT": null, 
                "F_VeV": null, 
                "F_VeP": null, 
                "F_IdV": "Noun:1740", 
                "F_IdT": 2, 
                "F_EvP": null, 
                "A_AId": null, 
                "F_EvT": null, 
                "F_Dl": null
            }, 
            "_type": "edge", 
            "_inV": "40344", 
            "_id": "W30T-aZdO-2F0LaTPQKq", 
            "_label": "F-UP-A", 
            "_outV": "2618620"
        }
    ]
}

[zachkinstner]

The Gremlin used here (from WeaverTitanGraph):

_TRY.each{k,v->if((z=v.getProperty(k))){_PROP.put(k,z)}};

Maybe it needs to check z for null? I wonder if null properties (rather than omitted properties) are being added elsewhere.

[zachkinstner]

The corresponding vertex does not include null properties:

{
    "t": 52, 
    "r": [
        {
            "_properties": {
                "F_Cr": 635138469813140946, 
                "N_FT": 9, 
                "F_Id": 55352000579108864, 
                "F_Df": false, 
                "F_DeT": 7, 
                "F_Fa": 2, 
                "F_Co": 635138469813140946, 
                "F_IdV": "Noun:1740", 
                "F_IdT": 2
            }, 
            "_id": "2618620", 
            "_type": "vertex"
        }
    ]
}

[zachkinstner]

This returns false, as expected:

x=false; if ( g.V("Cl_NK", "entity").next().getProperty("test") ) { x=true; }; x;

[zachkinstner]

# RexConnect> query
#   ...script (0; string): _V0=g.v(2618620); _PROP=[:]; _TRY=[F_Fa:_V0,F_Df:_V0,F_Cr:_V0,F_DeT:_V0,F_DiT:_V0,F_DiP:_V0,F_DiR:_V0,F_EvT:_V0,F_EvP:_V0,F_EvD:_V0,F_IdT:_V0,F_IdV:_V0,F_LoT:_V0,F_LoX:_V0,F_LoY:_V0,F_LoZ:_V0,F_VeT:_V0,F_VeU:_V0,F_VeP:_V0,F_VeV:_V0]; _TRY.each{k,v->if((z=v.getProperty(k))){_PROP.put(k,z)}}; _PROP;
#   ...params (1; string; opt): 
#   ...cache (2; int; opt): 

{"t":50,"r":[{"F_Cr":635138469813140946,"F_Fa":2,"F_IdV":"Noun:1740","F_IdT":2,"F_DeT":7}]}

# RexConnect> query
#   ...script (0; string): _V0=g.v(2618620); _PROP=[:]; _TRY=[F_Fa:_V0,F_Df:_V0,F_Cr:_V0,F_DeT:_V0,F_DiT:_V0,F_DiP:_V0,F_DiR:_V0,F_EvT:_V0,F_EvP:_V0,F_EvD:_V0,F_IdT:_V0,F_IdV:_V0,F_LoT:_V0,F_LoX:_V0,F_LoY:_V0,F_LoZ:_V0,F_VeT:_V0,F_VeU:_V0,F_VeP:_V0,F_VeV:_V0]; x="... "; _TRY.each{k,v->if((z=v.getProperty(k))){ x += k+':'+v+'='+z+' ... '; }}; x;
#   ...params (1; string; opt): 
#   ...cache (2; int; opt): 

{"t":187,"r":["... F_Fa:v[2618620]=2 ... F_Cr:v[2618620]=635138469813140946 ... F_DeT:v[2618620]=7 ... F_IdT:v[2618620]=2 ... F_IdV:v[2618620]=Noun:1740 ... "]}

[zachkinstner]

Further tests show that the null properties are added after committing a transaction. I think this issue is related to Fabric's data types setup for Titan:

g.makeType()
    .name("F-UP-A")
    .primaryKey(F_Fa,F_Df,F_Cr,F_DeT,F_DiT,F_DiP,F_DiR,F_EvT,F_EvP,F_EvD,F_IdT,F_IdV,F_LoT,F_LoX,F_LoY,F_LoZ,F_VeT,F_VeU,F_VeP,F_VeV,A_Cr)
    .signature(F_Id,F_Dl,F_Co,F_No,N_FT,A_AId)
    .unique(OUT);

After committing, any of these properties which were not already set become new null properties. I'm not sure if this is a bug with Titan, or if it is expected. It seems reasonable for the primaryKey properties to always be set.

In any case, using the has('F_LoT') function (against a null property) provides the expected, non-matching result.

[zachkinstner]

I created a Titan issue for this potential bug.