After defining a graph and filling it with some vertices and edges (see part 1), the time has come to retrieve information out of the graph.

Please take a look at the defined graph operations of ArangoDB. These will be the base for our next examples. (Yes, there may be other ways to get the results, this post does not claim completeness!)

We will start with some easy stuff and then smoothly advance in complexity.

Question: “How many edges are defined within the graph?”


First we have to define an AQL-query:

In our example we only have “plain” edges, that means no additional information was stored with the edges. Thus we expect a set of com.arangodb.entity.PlainEdgeEntity as result.

result now contains maximum 10 edges (defined in the last parameter). With the 3rd parameter set to true, the number of results of the query is calculated. So this is the number of edges:

Question: “How do I get the number of publications of a given person?”


We use the same function, but provide some options and a vertex example. In this case we take person2 as our person of interest (in our example: “Floyd”).

As before, the first parameter of the AQL-function GRAPH_EDGES is the name of the database. The second is the example vertex. We use one specific vertex (“Floyd”), so in our case it’s sufficient to provide the ID of this vertex. Least the options are defined: We only want to get the outgoing edges of our vertex (defined with direction) and all edges have to be stored in the collection defined with edgeCollectionRestriction.

That vertex example was easy. What about a more unspecific example? Maybe you want to get all publications of persons which have a “master of arts” title. Let’s add another person with a publication to the database.

Now there are two ways of creating a vertex example (in this case): Use an object of the class Person or create a Map. Let’s do both.

First the object: As the class Person only consists of non primitive datatypes (two attributes of type String) create an object with name set to null

Object will be serialized, so the first parameter (name) will not be used as filter criteria.

Second the map:

The results of the following two queries are equal:

Question: How do I get the titles of all publications of a specific person?


As result we expect a set of Publication. We know that persons and publications are connected via edges in “HasWritten”. So they are direct neighbors. A possible query might look like the following: