Traversing the Directed Edge

GSQL
#1

I am trying to query the graph, which gives all the connected nodes with their one hop away neighbors.
All the Edges present in the graph are DIRECTED, but I want to get all the connected nodes irrespective of their direction(all the incoming and outgoing edges).

Query -
one_hop = select b from allVertices:a - (ANY:rel) - ANY:b
WHERE a.type != “Gender” AND b.type != “Gender”;

which throws the following error -
unsatisfiable FROM pattern, query result always empty
Warning: unsatisfiable pattern allVertices:a - (ANY:rel) - ANY:b

And when direction is specified -

image
image1411×356 65.7 KB

It throws the above error.

So the questions are -

  1. If we have all the directed edges in the graph, can we query without specifying the direction.
  2. Do the source and target should only be those which are present as source and target respectively in the schema. If yes, how to filter them. (Refer Image - Gender is not source for any edge type in the graph).

=================================================================
More explanation for question 2 -
Consider schema as -
(Employee, Student) - (Reside>:r)-(City:c)

now I want to query-

s = {ANY.*}
p = select s from s-(Reside>:r)-City:c where s.type != Contractor

Contractor is not the source vertex for city.

#2

@muskansapolia For question 2 is type an attribute of Employee? If you are using “Type” as an attribute name it may be conflicting with reserve words.

Employee

  • fName
  • lName
  • Status

Employee

  • Jon
  • Doe
  • Contractor

This would be valid:

    start = {ANY.*}
    p = SELECT s FROM start:s -(Reside>:r) - City:c WHERE s.Status != Contractor
#3

@Jon_Herke I believe “type” is built-in as an attribute for all vertices and edges, and it outputs the internal type of the object as a STRING.

#4

@muskansapolia

  1. If all edges in your graph are directed, you can query them without specifying direction only if you declare a reverse edge for each of them. Then, you can treat (DIRECTED_EDGE|reverse_DIRECTED_EDGE) as a single undirected edge which encapsulates the two possible edge directions between a pair of vertices (in Syntax v1).

  • In a Syntax v2 SELECT statement, you would express it like this instead: (DIRECTED_EDGE>|reverse_DIRECTED_EDGE>)

  • I believe that (ANY>) should also work as you use it in the example

  1. The idea behind your type filtering does make sense (and is possible), but for the type “attribute”, you actually have to provide type comparisons that exist in the schema. This means that you can’t supply “Gender” or “Contractor” as arguments, as these are not real (possible) vertices in the graph.
  • Thus, a.type != “Gender” is not valid but a.type != “Employee” is
1 Like