Is MapAccum an implied SumAccum?

GSQL
#1

We have recently upgraded our TigerGraph version, and I have two instances of the same query over the same data having different results. One of the things I have diagnosed is an apparent change in the behavior of a MapAccum < STRING, INT > @@myMap or MapAccum <INT, INT> @@myMap

Previously, if I did this : ACCUM @@myMap += (value -> 1)
The integer would accumulate - but I have a query running right now where I always get a 1.

It would seem that the change is MapAccum < INT, SumAccum < INT >> @@myMap

But the question remains - did something change? is the nested SumAccum required?

#2

After a bit more testing - I believe that this behavior only occurs on MapAccum < INT, INT > not the MapAccum < STRING , INT >

#3

The behavior really should be consistent between versions and between different key types.

I will communication with the language team regarding this issue.

#4

In your case, please define your map like:

MapAccum<STRING, SumAccum> to enforce the behavior.

Thanks.

#5

I verified our source code of MapAccum. I do not think we did any logic change for the += operator.
And I checked for the release versions 3.1.6, 3.2.1 and our dev version with test cases below, the results are all expected and consistent.

create query test() for graph poc_graph {
  MapAccum<int, int> @@myMap;
  MapAccum<string, int> @@myMap2;
  @@myMap += (1 -> 1);
  print @@myMap;
  @@myMap += (1 -> 1);
  print @@myMap;
  print @@myMap.get(1);

  @@myMap2 += ("Tom" -> 1);
  print @@myMap2;
  @@myMap2 += ("Tom" -> 1);
  print @@myMap2;
  print @@myMap2.get("Tom");
}

Could you provide the version of TigerGraph you observed this change? We could help to verify if there is anything wrong with it.

Thanks.

#6

I have recreated the issue on 3.2.2 in a simple query - can I email it directly to you?

#7

@markmegerian just sent you a direct message with emails.