# Match on circular graph

I have use case with vertexes and edges like:

A-(B)-C-(D)-E-(F)-A

Just say that I start with A and select form A-(B)-C-(D)-E with a WHERE condition, so getting a subset of E, say “e_sub1”.

What I’d like is to filter e_sub1 if the F relationship exists and if a certain property on the relationship is set to true.

What’s the best way to do this?

When I try something like:

``````Start{a}

e_sub1 = SELECT e FROM Start-(B)-C-(D)-E:e

WHERE e.search_key like term;

f = SELECT f FROM e_sub1-(F:f)-Start

WHERE f.hide == true;

e_toRemove = SELECT e from f-E:e;

PRINT  e_sub1 MINUS e_toRemove;
``````

I get Undefined vertex type “Start”

I also tried:

``````Start{a}

e_sub1 = SELECT e FROM Start-(B)-C-(D)-E:e

WHERE e.search_key like term;

e_sub2 = SELECT e FROM Start-(F:f)-E:e

WHERE

e IN e_sub1

f.hide == true

PRINT e_sub2;
``````

However, there was a problem with e_sub1 not being recognised as a variable.

The only way I can see at the moment is something like:

``````Start{a};

e_sub1 = SELECT e FROM Start-(B)-C-(D)-E:e

WHERE e.search_key like term;

e_sub2 = SELECT e FROM Start-(F:f)-E:e

WHERE

f.hide == true;

res = e_sub1 MINUS e_sub2;

RETURN res;
``````

But this seems like it could be more efficient.

Hi Rene,

1. If you’re copy-pasting your code, the reason why Start is undefined is because it should be `**Start = {a};**`

There should be another error on this line, if that is what you actually typed.

``````2. f = SELECT f FROM e_sub1-(F:f)-Start

WHERE f.hide == true;
``````

You cannot select an edge.

1. Using your bottom query that works, I’ve changed it to this :
``````e_sub1 = SELECT e FROM Start-(B)-C-(D)-E:e

WHERE e.search_key like term;

e_sub2 = SELECT a FROM e_sub1-(F:f)-A:a

WHERE f.hide == true;

return e_sub2;
``````

Thanks,

Kevin

Hi Kevin,

Good pick up.

I didn’t cut and paste, but abstracted and there were some syntax errors introduced - sorry about that.

What you’ve written:

``````e_sub2 = SELECT a FROM e_sub1-(F:f)-A:a

WHERE f.hide == true;
``````

is not returning an E type, it’s returning a.

What I actually need is the subset of e_sub1 where the f relationship doesn’t exist or f.hide == false.

Cheers,

Rene

I experimented a little more any it appears that the SELECT portion of a GSQL statement has a hard limit of 1 input variable, which is the first variable encountered. All the other variables in the SELECT statement are possibly interpreted as output variables.

EG

f = SELECT f FROM Start-(F:f)-E:e_sub1

`````` WHERE f.hide == true;
``````

e_sub1 is used as a vSet name already

Hey Rene,

From what I previously sent you,

edit the select statement to this:
e_sub2 = select e from e_sub1:e-(F:f)-A:a
where f.hide == false;

-Kevin

Hi Kevin,

Thanks for the response

Unfortunately that doesn’t compile - it complains:

“The alias name ‘a’ is used as a parameter already.”

If I replace “A:a” with “Start”, it complains “undefined vertex name ‘Start’”

Rene,

Change the ‘a’ to something else.

I’ve tried changing it, but then I need to provide an extra where clause to filter on the same id as provided by the input parameter a. This is doesn’t work because the syntax checker stops me from referring to the v_id and doesn’t recognise the attribute that is used as the primary_id as an attribute (see “attributes missing from data”). Also - it would be suboptimal to have to filter again. We already have the vertex, I’d like to be able to re-use it in a subsequent query rather than looking it up again.

Cheers,

Rene

To clarify, now that my other question “attributes missing from data” is closed, the problem here is that we can’t reuse two different variables within a query. EG we already have ‘a’, I’d like to know if there is a way to reuse it, rather than searching for it again.

For benefit of others - there can only be one VertexSet input to the query

Rene,

A query can take multiple vertex set parameter. E.g.

# schema setup

CREATE VERTEX company(PRIMARY_ID companyId string, id string compress, label bool, company_name string default “unknown”, nCount int)

CREATE VERTEX members(PRIMARY_ID memberId string, id string, profileIndustryId string default “0”, registrationDate uint default 0)

CREATE VERTEX skill(PRIMARY_ID skillId string, id string, nCount string)

CREATE UNDIRECTED EDGE member_work_company(FROM members, TO company, positionId double, industryId real, startTime int)

CREATE DIRECTED EDGE member_follow_company(FROM members, TO company, createTime int)

CREATE UNDIRECTED EDGE member_member(FROM members, TO members, create_time int)

CREATE DIRECTED EDGE member_skill(FROM members, TO skill)

CREATE DIRECTED EDGE member_to_all (FROM members, TO *)

CREATE UNDIRECTED EDGE all_to_skill (FROM *, TO skill)

CREATE DIRECTED EDGE all_to_all (FROM *, TO *)

CREATE GRAPH test_graph(*)

create query test5 (set<vertex> mem, set<vertex> com, set<vertex> ski) for graph test_graph {

Mem = mem;

print Mem.id;

Com = com;

print Com.id;

Ski = ski;

print Ski.id;

# Union

MemCom = (Mem) union Com;

print MemCom.id;

MemMem = Mem union Mem;

print MemMem.id;

ComSkill = (Com union Ski);

print ComSkill.id;

# Intersect

MemCom_ComSkill = MemCom intersect ComSkill;

print MemCom_ComSkill.id;

MemCom_Com = ((MemCom) intersect (Com));

print MemCom_Com.id;

# Minus

MemCom0Mem = MemCom minus Mem;

print MemCom0Mem.id;

MemCom0MemCom = MemCom minus MemCom;

print MemCom0MemCom.id;

ComSkill0Mem = ComSkill minus Mem;

print ComSkill0Mem.id;

}

GSQL > install query test5

GSQL > run query test5([“m1”, “m2”, “m3”], [“c1”, “c2”], [“s3”, “s5”])

Hi Mingxi,

Sorry - to be specific, there can be only one vSetVar informing a SELECT query.

Cheers,

Rene

Hi Rene, just to follow this, and I have read the thread but apologies if I missed it:

Are you specifically looking to use a vertex set as a restriction on a traversal? So you have your starting point (which is the current normal use of a vertex set), and a path, with a restriction on a target vertex type along that path?

We usually do that with a WHERE clause or by an INTERSECT between sets. The INTERSECT is efficient but more memory consuming.

But then maybe I’m missing the point :).