MapAccum/MinAccum and Tuples issues

#1

Using 2.5, while traversing my graph I’m trying to keep track of the shortest path to each of many starting seeds. To do this I’m using a tuple which contains the depth of the preceding vertex and the preceding vertex. I use a MapAccum so that I can store the minimum (i.e. closest) one of these tuples for each Map key (seed vertex). What I have is something like this:

TYPEDEF TUPLE <depth Int, v Vertex> connectPred
MapAccum<Vertex, MinAccum<connectPred>> @predecessors;

result = SELECT v FROM seed:u--ANY:v
             ACCUM FOREACH (k, val) IN u.@predecessors DO
               v.@predecessors += (k -> connectPred(val.depth + 1, val.v))
             END;

So I want to update the entries in v.@predecessors if u.@predecessors contains a closer predecessor vertex for the same key. However this gives me an error:

Error: No field can be accessed by 'val' of non-tuple type

However val SHOULD be a tuple type. So this seems like a bug to me. Any workarounds? Is this fixed in recent versions? Essentially GSQL seems to not be properly handling MinAccum of tuple type.

#2

Hi,
First, good use of accumulators. You’re past the beginning level onto immediate stuff.

I believe there is an error at the end of this statement:
v.@predecessors += (k -> connectPred(val.depth + 1, val.v))
The term val.v is incorrect. There are two issues:

  1. Logic:
    I don’t think you want to copy this value from @predecessor of u. I think you want to update it to the predecessor of v, which is u, right?
    v.@predecessors += (k -> connectPred(val.depth + 1, u))
  2. Syntax:
    Where the logic is right or not, why didn’t val.v work?
    val is a MinAccum of type connectPred, so its output should be tyoe connectPred, and we should be able to access its field v.
    My guess is that syntax checker is being overly finicky and saying that accum is not the same as a tuple.
#3

Yes you’re right about the logic error, I meant to write u instead of val.v.

For the syntax issue, is there any way to work around it?

#4

If you replace val.v with u, you won’t have the syntax problem.

I think more testing is needed to see if my guess about the syntax checker is correct.

#5

If I fix that logic error, I get the same tuple error for val.depth so the problem remains. Also to provide additional information when I try to install the query using the CLI I get this message:

Semantic Check Error in query connect_vertices (SEM-530): line [24, 43]
No field can be accessed by 'val' of non-tuple type