Are 'WHERE item IN accumulator' statements allowed?

#1

Consider the following pseudocode SELECT statements:

SetAccum<STRING> @@set_ids;

some_result = SELECT v2t FROM vertextype -(edgetype)- vertex2type:v2t
                ACCUM @@set_ids += v2t.my_id;

interesting_result = SELECT v FROM vertextype:v -(edge2type:edge_w_id)- vertex3type
                WHERE edge_w_id.my_id IN @@set_ids;

The first query is fine, but I cannot find a viable means to perform the second query. The error I get is in the WHERE clause and it states something like: “no type can be inferred for edge_w_id.my_id” which is unfortunate because its clearly defined in the schema what type it is and if you replace IN @@set_ids with == "123" the compiler does recognize this is a string and the query builds without issue.

Are these types of queries possible? Am I missing something from within the documentation?

#2

The idea behind what you are trying to do is possible, but it needs to be done with a built-in accumulator function instead of the “WHERE IN” syntax.

You can use @@set_ids.contains(edge_w_id.my_id) instead of edge_w_id.my_id IN @@set_ids

[SetAccum documentation]

2 Likes
#3

Thanks for explaining this. I’ll likely refactor my solution to match this later on.

For now I was able to resolve the issue with the types in a different way. This probably isn’t preferred but I found that if I made the interesting_result query into a sub query I could use arguments with types like
```

  • SET<VERTEX> source, SET set_ids,*
    ```
    that allowed for the _. in __ syntax to work as well.

EDIT: I take back what I said in the above text. What I suggested very much broke tigergraph(server still runs but the compiler doesn’t know it can’t do what I wanted it too)

So I will use the approach shared above!

2 Likes
#4

I’m slightly late to this. Can I ask, what is the intent here? I’ll set it up anyway, but your construction is unusual, so I’m wondering if there may be alternatives that have the same effect.

1 Like
#5

OK. I set it up locally and your code works fine. Here is my code plus a functional alternative which I wouldn’t recommend (it may well be slow) but might be useful.

I suspect there is also a conjunctive pattern matching way of doing this too, but I’ll leave that to others :).

CREATE QUERY test1() FOR GRAPH new_graph SYNTAX V2 { 
 SetAccum<STRING> @@set_ids;

some_result = SELECT v2t FROM vt1 -(et1)- vt2:v2t
                ACCUM @@set_ids += v2t.id;

interesting_result = SELECT v FROM vt1:v -(et2:edge_w_id)- vt3
                WHERE 
                    edge_w_id.my_id IN @@set_ids;
  
  
all_in_one = select v from vt1:v - (et2:edge_w_id)- vt3:v3
            WHERE
                edge_w_id.my_id IN v.neighborAttribute("et1", "vt2", "id");
  
}
1 Like
#6

I was able to make the solution from Ishestakov work just fine and in basic testing it works fast enough :).

The intent is slightly obfuscated because the actual need is pretty intense. It involves a conditional operation based on properties of a forked node (A -> (B->C, B->E)). To add more mud to the water A is the result of a traversal. All that said - I was able to get the other bits to work with some help from Leo S.

I like the approach with v.neighborAttribute(). I’ll keep that one under the hat.

2 Likes