Hawkin
/
arangodb
mirror of https://gitee.com/bigwinds/arangodb
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Minor documentation fixes

This commit is contained in:
Michael Hackstein 2015-12-03 16:40:48 +01:00
parent bf83a0e6a2
commit 4003caa116
1 changed files with 17 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
Documentation/Books/Users/Aql/GraphTraversals.mdpp
View File

@ -13,11 +13,19 @@ For all vertices that where visited during this process in the range between *mi
2. The edge pointing to it
3. The complete path from start-vertex to the visited vertex as a JSON document with an attribute `edges` and an attribute `vertices`, each a list of the coresponding elements. These lists are sorted, s.t. the first element in `vertices` is the start-vertex and the last is the visited vertex. And that the n-th element in `edges` connects the n-th element with the (n+1)-th element in `vertices`.
Let's take a look at a simple example to explain how it works:
!SUBSUBSECTION Example execution
Let's take a look at a simple example to explain how it works.
This is the graph that we are going to traverse:
![traversal graph](../Graphs/traversal_graph.png)
At first we have to define a starting point **A**:
Now we use the following parameters for our query:
1. We start at the vertex **A**.
2. We use a *min-depth* of 1.
3. We use a *max-depth* of 2.
4. We follow only *outbound* direction of edges
![traversal graph step 1](../Graphs/traversal_graph1.png)
@ -30,7 +38,7 @@ Now again it will visit one of the direct neighbors of **B**, say **E**:
![traversal graph step 3](../Graphs/traversal_graph3.png)
Now assume we have limited the query with a *max-depth* of *2* then it will not pick any neighbor of **E** as the path from **A** to **E** already requires *2* steps.
We have limited the query with a *max-depth* of *2* then it will not pick any neighbor of **E** as the path from **A** to **E** already requires *2* steps.
Instead we will go back one level to **B** and continue with any other direct neighbor there:
![traversal graph step 4](../Graphs/traversal_graph4.png)
@ -63,7 +71,7 @@ So all together this query has returned the following paths:
!SUBSECTION Syntax
Now let's see how we can write a query that follows this schema.
You have to options here, you can either use a managed graph (see [the graphs chaper]() on how to create it)
You have two options here, you can either use a managed graph (see [the graphs chaper]() on how to create it)
!SUBSUBSECTION Working on managed graphs:
@ -97,23 +105,23 @@ Instead of the `GRAPH graphName` you may specify a **list of edge collections**.
!SUBSECTION using filters and the explainer to extrapolate the costs
All three variables emitted by the traversals might as well be used in filter statements.
For some of these filter statements the optimizer can detect that it is possible to prune paths of traversals earlier, hence invalid results will not be emitted to the variables in the first place.
For some of these filter statements the optimizer can detect that it is possible to prune paths of traversals earlier, hence filtered results will not be emitted to the variables in the first place.
This may significantly improve the performance of your query.
Whenever a filter is not fulfilled the complete set of **vertex**, **edge** and **path** will be skipped.
All paths with a length greater than `MAX` will never be computed.
In the present state OR combined filters cannot be optimized, AND combined filters can.
In the current state `OR` combined filters cannot be optimized, `AND` combined filters can.
!SUBSUBSECTION filtering on paths
This allows for the most powerful filtering and may have the highest impact on performance.
Using the path variable you can filter on specific iteration depths.
You can filter for absolute positions in the path by **(specifying a positive number)** **(which then qualifies for the optimizations)** or relative positions to the end of the path by specifying a negative number.
**Note**: In the present state there is no way to define **for all elements on the path**. This will be added in the future.
**Note**: In the current state there is no way to define **for all elements on the path**. This will be added in the future.
*Filtering edges on the path*
FOR v,e,p IN 0..5 OUTBOUND 'circles/A' GRAPH 'traversalGraph' FILTER p.edges[0].theTruth == true return p
FOR v, e, p IN 1..5 OUTBOUND 'circles/A' GRAPH 'traversalGraph' FILTER p.edges[0].theTruth == true return p
will filter all paths where the start edge (# 0) has the attribute `theTruth` equaling true.
The resulting paths will be up to 5 items long.
@ -121,7 +129,7 @@ The resulting paths will be up to 5 items long.
*combining several filters*
FOR v,e,p IN 0..5 OUTBOUND 'circles/A' GRAPH 'traversalGraph' FILTER p.edges[0].theTruth == true AND p.edges[1].theFalse == false RETURN p
FOR v, e, p IN 1..5 OUTBOUND 'circles/A' GRAPH 'traversalGraph' FILTER p.edges[0].theTruth == true AND p.edges[1].theFalse == false RETURN p
will filter all paths where the start edge (# 0) has the attribute `theTruth` equaling true and the second edge (# 1) having the attribute `theFalse` equaling false.
The resulting paths will be up to 5 items long.