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?
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)
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.
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");
}
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.