Casting List to Set within Accumulator statement

GSQL
1

Is there a way to convert LIST to a SET within an accumulator statement?

In this GSQL query I am constructing triples (technically quads), and need to pull a property from the edge to compute the last entry.

A code example:

CREATE QUERY getTriples() FOR GRAPH SomeGraph SYNTAX v2 { 
    TYPEDEF TUPLE <VERTEX src, EDGE edg, VERTEX dest, STRING year> TUPLE_RECORD;
    SetAccum<TUPLE_RECORD> @@triples;

    p = ANY;

    res = SELECT tgt FROM p:s - (:e1) - :tgt WHERE s!=tgt
               ACCUM @@triples += TUPLE_RECORD(s, e1, tgt, subGetYearProp(e1.listOfStringProperty));

    PRINT @@triples;
}

The edge property listOfStringProperty is a List<String> in the graph schema. For example ["2010", "2012", "1974"] . Now I want to compute something over this property, for example the min value. However, (sub)queries do not take LIST as arguments, only SET or BAG. For example:

CREATE QUERY subGetYearProp(SET<STRING> years) RETURNS (MinAccum<STRING) {
    MinAccum<STRING> @@minYear;

    FOREACH yr in years DO
        @@minYear += yr
    END;

   RETURN @@minYear;
}

Within getTriples() the subquery subGetYearProp will not compile because it expects a SET but is given a LIST. Is there a performant way to cast e1.listOfStringProperty to a SET within the ACCUM where the triples are constructed?

I have a solution with a global accumulator to build a map of SetAccums for those properties, but that requires a second loop over all edges to then construct the triple set.

2

Doesn’t a BAG work instead of a SET?

3

I have tried with the subQuery argument type as BAG<STRING> years, but when I write subGetYearProp(e1.listOfStringProperty) I get the error:

Error: incompatible argument types for function/tuple subGetYearProp

so it seems that the subquery doesnt get the edge property type correctly?

4

Am I the only one that isn’t loving the idea of a List as an attribute for the edge?

Seems like that creates unnecessary complexity, makes the Accumulators harder to implement, and could just as easily be achieved by having multiple edges each with their own year?

5

The example I described in the original post is just to illustrate the problem. I agree with you that in the specific case of an edge attribute that is a List of years, one may want to consider splitting into multiple edges.

The core problem remains though, is there something preventing the execution of (sub)queries on list attributes of edges?