IN clause in WHERE/HAVING

Hi,
Pardon me for crossposting. I have crystalized the earlier problem to the IN in WHERE/HAVING. c_list is a ListAccum<VERTEX>>. So I think, the WHERE clause should do an IN to check membership. Thoughts ? Pointers ?
Cheers & Thanks (i have a few more steps to go before submitting for the Challenge !

CREATE QUERY ops_02(/* Parameters here */) FOR GRAPH Tumbler {
ListAccum<ListAccum<VERTEX>> @@cycles_list;
ListAccum<ListAccum> @@edges_list;
ListAccum @@edges;
// VERTEX s_node, t_node;
@@cycles_list = rt_cycle();
FOREACH c_list IN @@cycles_list DO
PRINT(c_list);
Start = {c_list};
res = SELECT s FROM Start:s - (send:e) → account:tgt
//WHERE tgt IN [c_list]
ACCUM
@@edges += e
//HAVING tgt IN [c_list]
;
//PRINT(@@edges);
@@edges_list += @@edges;
END;
// PRINT(@@cycles_list);
PRINT(@@edges_list);
}

Hi Ksankar!

From my understanding, you’re looking to select Vertices from c_list that connect via an edge to another vertex in c_list.

In this case, you don’t need to use the WHERE tgt IN [c_list] or the HAVING tgt IN [c_list]. Since your Start variable is the same list of vertices as c_list, you can simply write your select statement like this:

res = SELECT tgt FROM Start:s - (send:e) -> Start:tgt
ACCUM
  @@edges += e;

Because c_list is Start, the above SELECT statement will only select tgt vertices that are also in the Start set.

1 Like

Dan,
Thanks. I didn’t realize one can select tgt as well ! Good idea, I will try.
Cheers
/k

1 Like

Dan,
Doesn’t work - gives the “mixed usage of v1 and v2 syntax” error ;o(


Cheers
/k

@ksankar V2 syntax moves the directional arrow inside the -(edge>:e)- . Using this does it resolve the error message?

It gets into all kinds of troubles ;o(


Also gives errors in later SELECT statements - which were working before.

Hey, sorry to throw a wrench in the works here, but I don’t think this is valid syntax. In this example, the Start is a vertex set established in the query logic, which is valid to use as the “seed” set for a query. But I am pretty sure you can’t also use it for later hops in your query logic, since anything beyond the seed set must be a valid vertex name in your schema.