Repository: tinkerpop Updated Branches: refs/heads/tp32 0bd9b5ae7 -> dde73e42b
Consistent format of step references should use a dash CTR Project: http://git-wip-us.apache.org/repos/asf/tinkerpop/repo Commit: http://git-wip-us.apache.org/repos/asf/tinkerpop/commit/dde73e42 Tree: http://git-wip-us.apache.org/repos/asf/tinkerpop/tree/dde73e42 Diff: http://git-wip-us.apache.org/repos/asf/tinkerpop/diff/dde73e42 Branch: refs/heads/tp32 Commit: dde73e42bc1aed1e73b71a38aa51a9c4641ef562 Parents: 0bd9b5a Author: Stephen Mallette <sp...@genoprime.com> Authored: Fri Jul 27 07:16:11 2018 -0400 Committer: Stephen Mallette <sp...@genoprime.com> Committed: Fri Jul 27 07:16:11 2018 -0400 ---------------------------------------------------------------------- docs/src/dev/developer/for-committers.asciidoc | 2 +- docs/src/recipes/between-vertices.asciidoc | 6 +++--- docs/src/recipes/collections.asciidoc | 18 +++++++++--------- docs/src/recipes/pagination.asciidoc | 2 +- .../recipes/traversal-component-reuse.asciidoc | 4 ++-- docs/src/recipes/tree.asciidoc | 2 +- docs/src/reference/the-traversal.asciidoc | 2 +- docs/src/tutorials/getting-started/index.asciidoc | 12 ++++++------ .../src/tutorials/gremlins-anatomy/index.asciidoc | 16 ++++++++-------- .../tutorials/the-gremlin-console/index.asciidoc | 2 +- 10 files changed, 33 insertions(+), 33 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/dde73e42/docs/src/dev/developer/for-committers.asciidoc ---------------------------------------------------------------------- diff --git a/docs/src/dev/developer/for-committers.asciidoc b/docs/src/dev/developer/for-committers.asciidoc index 43c9ce3..82b3609 100644 --- a/docs/src/dev/developer/for-committers.asciidoc +++ b/docs/src/dev/developer/for-committers.asciidoc @@ -366,7 +366,7 @@ in it * "the result should be ordered" - the exact results and should appear in the order presented * "the result should be unordered" - the exact results but can appear any order * "the result should be of" - results can be any of the specified values and in any order (use when guarantees -regarding the exact results cannot be pre-determined easily - see the `range()` step tests for examples) +regarding the exact results cannot be pre-determined easily - see the `range()`-step tests for examples) These final three types of assertions mentioned above should be followed by a Gherkin table that has one column, where each row value in that column represents a value to assert in the result. These values are type notation respected as http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/dde73e42/docs/src/recipes/between-vertices.asciidoc ---------------------------------------------------------------------- diff --git a/docs/src/recipes/between-vertices.asciidoc b/docs/src/recipes/between-vertices.asciidoc index a947d3b..b32d323 100644 --- a/docs/src/recipes/between-vertices.asciidoc +++ b/docs/src/recipes/between-vertices.asciidoc @@ -33,7 +33,7 @@ g.V(1).out().where(__.in().hasId(6)) <6> ---- <1> There are three edges from the vertex with the identifier of "1". -<2> Filter those three edges using the `where()` step using the identifier of the vertex returned by `otherV()` to +<2> Filter those three edges using the `where()`-step using the identifier of the vertex returned by `otherV()` to ensure it matches on the vertex of concern, which is the one with an identifier of "2". <3> Note that the same traversal will work if there are actual `Vertex` instances rather than just vertex identifiers. <4> The vertex with identifier "1" has all outgoing edges, so it would also be acceptable to use the directional steps @@ -43,7 +43,7 @@ vertices with identifiers "2" and "3". <6> There's no reason why the same pattern of exclusion used for edges with `where()` can't work for a vertex between two vertices. -The basic pattern of using `where()` step to find the "other" known vertex can be applied in far more complex +The basic pattern of using `where()`-step to find the "other" known vertex can be applied in far more complex scenarios. For one such example, consider the following traversal that finds all the paths between a group of defined vertices: @@ -113,6 +113,6 @@ g.V(vRexsterJob1, vBlueprintsJob1).as('job'). ---- While the traversals above are more complex, the pattern for finding "things" between two vertices is largely the same. -Note the use of the `where()` step to terminate the traversers for a specific user. It is embedded in a `coalesce()` +Note the use of the `where()`-step to terminate the traversers for a specific user. It is embedded in a `coalesce()` step to handle situations where the specified user did not complete an application for the specified job and will return `false` in those cases. http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/dde73e42/docs/src/recipes/collections.asciidoc ---------------------------------------------------------------------- diff --git a/docs/src/recipes/collections.asciidoc b/docs/src/recipes/collections.asciidoc index 257d661..2b1b169 100644 --- a/docs/src/recipes/collections.asciidoc +++ b/docs/src/recipes/collections.asciidoc @@ -86,7 +86,7 @@ g.V(). ---- The call to `local()` executes its anonymous sub-traversal over each individual `List` iterator and as the -sub-traversal ends with a `fold()` step, the results are reduced back into a `List` to preserve the original structure, +sub-traversal ends with a `fold()`-step, the results are reduced back into a `List` to preserve the original structure, thus maintaining two traverser results. This pattern for unfolding and folding `List` traversers ends up having other applications: @@ -112,7 +112,7 @@ g.V().union(limit(3).fold(),tail(3).fold()). <3> with the highest degree (i.e. number of edges). By ending with `fold()` the `List` traverser structure is preserved thus returning two `List` objects. Consider this a method for choosing a "max" or a highly ranked vertex. In this case the rank was determined by the number of edges, but it could have just as easily been determined by a vertex property, -edge property, a calculated value, etc. - one simply needs to alter the `by()` step modulator to `order()`. +edge property, a calculated value, etc. - one simply needs to alter the `by()`-step modulator to `order()`. <3> For each `List` of vertices, filter that `List` to only include vertices that have an "age" property with a value greater than or equal to "29" and then average the results of each list. More generally, consider how this approach performs some kind of reducing calculation on each `List` traverser. In this case, an average was calculated, @@ -194,11 +194,11 @@ the `mean()` to store in a `List` called "c". Note that `aggregate()` was used h the former is an eager collection of the elements in the stream (`store()` is lazy) and will force the traversal to be iterated up to that point before moving forward. Without that eager collection, "v" and "e" would not contain the complete information required for the production of "b" and "c". -<6> Adding `fold()` step here is a bit of a trick. To see the trick, copy and paste all lines of Gremlin up to but -not including this `fold()` step and run them against the "modern" graph. The output is three vertices and if the -`profile()` step was added one would also see that the traversal contained three traversers. These three traversers -with a vertex in each one were produced from the `repeat()` step (i.e. those vertices that had the "lang" of "java" -when traversing away from "marko"). The `aggregate()` steps are side-effects and just allow the traversers to pass +<6> Adding `fold()`-step here is a bit of a trick. To see the trick, copy and paste all lines of Gremlin up to but +not including this `fold()`-step and run them against the "modern" graph. The output is three vertices and if the +`profile()`-step was added one would also see that the traversal contained three traversers. These three traversers +with a vertex in each one were produced from the `repeat()`-step (i.e. those vertices that had the "lang" of "java" +when traversing away from "marko"). The `aggregate()`-steps are side-effects and just allow the traversers to pass through them unchanged. The `fold()` obviously converts those three traversers to a single `List` to make one traverser with a `List` inside. That means that the remaining steps following the `fold()` will only be executed one time each instead of three, which, as will be shown, is critical to the proper result. @@ -212,7 +212,7 @@ presents an override to include "c" into the result. All of the above code and explanation show that `store()` can be used to construct `List` objects as side-effects which can then be used as a result. Note that `aggregate()` can be used to similar effect, should it make sense that lazy `List` creation is not acceptable with respect to the nature of the traversal. An interesting sub-pattern that -emerges here is that the `by()` step can modulate its step to completely override the current traverser and ignore its +emerges here is that the `by()`-step can modulate its step to completely override the current traverser and ignore its contents for purpose of that step. This ability to override a traverser acts as a powerful and flexible tool as it means that each traverser can effectively become a completely different object as determined by a sub-traversal. @@ -361,7 +361,7 @@ g.V(). <1> The `valueMap(true)` of a `Vertex` can be extended with the "degree" of the `Vertex` by performing a `union()` of the two traversals that produce that output (both produce `Map` objects). -<2> The `unfold()` step is used to decompose the `Map` objects into key/value entries that are then constructed back +<2> The `unfold()`-step is used to decompose the `Map` objects into key/value entries that are then constructed back into a single new `Map` given the patterns shown earlier. The `Map` objects of both traversals in the `union()` are essentially merged together. http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/dde73e42/docs/src/recipes/pagination.asciidoc ---------------------------------------------------------------------- diff --git a/docs/src/recipes/pagination.asciidoc b/docs/src/recipes/pagination.asciidoc index c26a1fc..7e7da8d 100644 --- a/docs/src/recipes/pagination.asciidoc +++ b/docs/src/recipes/pagination.asciidoc @@ -64,7 +64,7 @@ NOTE: The first traversal above could also be written as `g.V().hasLabel('person In this case, there is no way to know the total count so the only way to know if the end of the results have been reached is to count the results from each paged result to see if there's less than the number expected or simply zero results. In that case, further requests for additional pages would be unnecessary. Of course, this approach is not -free of problems either. Most graph databases will not optimize the `range()` step, meaning that the second traversal +free of problems either. Most graph databases will not optimize the `range()`-step, meaning that the second traversal will repeat the iteration of the first two vertices to get to the second set of two vertices. In other words, for the second traversal, the graph will still read four vertices even though there was only a request for two. http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/dde73e42/docs/src/recipes/traversal-component-reuse.asciidoc ---------------------------------------------------------------------- diff --git a/docs/src/recipes/traversal-component-reuse.asciidoc b/docs/src/recipes/traversal-component-reuse.asciidoc index 3b9b408..c623531 100644 --- a/docs/src/recipes/traversal-component-reuse.asciidoc +++ b/docs/src/recipes/traversal-component-reuse.asciidoc @@ -20,7 +20,7 @@ limitations under the License. Good software development practices require reuse to keep software maintainable. In Gremlin, there are often bits of traversal logic that could be represented as components that might be tested independently and utilized as part of other traversals. One approach to doing this would be to extract such logic into an anonymous traversal -and provide it to a parent traversal through `flatMap()` step. +and provide it to a parent traversal through `flatMap()`-step. Using the modern toy graph as an example, assume that there are number of traversals that are interested in filtering on edges where the "weight" property is greater than "0.5". A query like that might look like this: @@ -42,7 +42,7 @@ g.V(1).flatMap(weightFilter).both() The `weightFilter` is an anonymous traversal and it is created by way `__` class. The `__` is omitted above from initalization of `weightFilter` because it is statically imported to the Gremlin Console. The `weightFilter` gets -passed to the "full" traversal by way for `flatMap()` step and the results are the same. Of course, there is a problem. +passed to the "full" traversal by way for `flatMap()`-step and the results are the same. Of course, there is a problem. If there is an attempt to use that `weightFilter` a second time, the traversal with thrown an exception because both the `weightFilter` and parent traversal have been "compiled" which prevents their re-use. A simple fix to this would be to clone the `weightFilter`. http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/dde73e42/docs/src/recipes/tree.asciidoc ---------------------------------------------------------------------- diff --git a/docs/src/recipes/tree.asciidoc b/docs/src/recipes/tree.asciidoc index f87784f..879b26e 100644 --- a/docs/src/recipes/tree.asciidoc +++ b/docs/src/recipes/tree.asciidoc @@ -154,7 +154,7 @@ single result. The previous approaches to calculating the maximum depth use path calculations to achieve the answer. Path calculations can be expensive and if possible avoided if they are not needed. Another way to express a traversal that calculates -the maximum depth is to use the `sack()` step: +the maximum depth is to use the `sack()`-step: [gremlin-groovy,existing] ---- http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/dde73e42/docs/src/reference/the-traversal.asciidoc ---------------------------------------------------------------------- diff --git a/docs/src/reference/the-traversal.asciidoc b/docs/src/reference/the-traversal.asciidoc index 057ec6a..970dfca 100644 --- a/docs/src/reference/the-traversal.asciidoc +++ b/docs/src/reference/the-traversal.asciidoc @@ -437,7 +437,7 @@ g.V().both().both().both().count().iterate().toString() <2> ---- <1> `LazyBarrierStrategy` is a default strategy and thus, does not need to be explicitly activated. -<2> With `LazyBarrierStrategy` activated, `barrier()` steps are automatically inserted where appropriate. +<2> With `LazyBarrierStrategy` activated, `barrier()`-steps are automatically inserted where appropriate. *Additional References* http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/dde73e42/docs/src/tutorials/getting-started/index.asciidoc ---------------------------------------------------------------------- diff --git a/docs/src/tutorials/getting-started/index.asciidoc b/docs/src/tutorials/getting-started/index.asciidoc index 11e2533..5d98c59 100644 --- a/docs/src/tutorials/getting-started/index.asciidoc +++ b/docs/src/tutorials/getting-started/index.asciidoc @@ -228,7 +228,7 @@ for the creation of link:http://tinkerpop.apache.org/docs/x.y.z/reference/#graph Second, don't forget that you are working with TinkerGraph which allows for identifier assignment. That is _not_ the case with most graph databases. -Finally, the `as()` steps label the value held at a particular step so that you can reference back to it later in the +Finally, the `as()`-steps label the value held at a particular step so that you can reference back to it later in the traversal. In this case, that allows you to reference both vertices as "v1" and "v2" during edge creation. === Graph Traversal - Staying Simple @@ -333,7 +333,7 @@ graph = TinkerFactory.createModern() g = graph.traversal() ---- -Earlier we'd used the `has()` step to tell Gremlin how to find the "marko" vertex. Let's look at some other ways to +Earlier we'd used the `has()`-step to tell Gremlin how to find the "marko" vertex. Let's look at some other ways to use `has()`. What if we wanted Gremlin to find the "age" values of both "vadas" and "marko"? In this case we could use the `within` comparator with `has()` as follows: @@ -393,13 +393,13 @@ g.V().has('name','marko').as('exclude'). ---- We made two additions to the traversal to make it exclude "marko" from the results. First, we added the -link:http://tinkerpop.apache.org/docs/x.y.z/reference/#as-step[as()] step. The `as()` step is not really a "step", +link:http://tinkerpop.apache.org/docs/x.y.z/reference/#as-step[as()] step. The `as()`-step is not really a "step", but a "step modulator" - something that adds features to a step or the traversal. Here, the `as('exclude')` labels -the `has()` step with the name "exclude" and all values that pass through that step are held in that label for later +the `has()`-step with the name "exclude" and all values that pass through that step are held in that label for later use. In this case, the "marko" vertex is the only vertex to pass through that point, so it is held in "exclude". -The other addition that was made was the `where()` step which is a filter step like `has()`. The `where()` is -positioned after the `in()` step that has "person" vertices, which means that the `where()` filter is occurring +The other addition that was made was the `where()`-step which is a filter step like `has()`. The `where()` is +positioned after the `in()`-step that has "person" vertices, which means that the `where()` filter is occurring on the list of "marko" collaborators. The `where()` specifies that the "person" vertices passing through it should not equal (i.e. `neq()`) the contents of the "exclude" label. As it just contains the "marko" vertex, the `where()` filters out the "marko" that we get when we traverse back _in_ on the "created" edges. http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/dde73e42/docs/src/tutorials/gremlins-anatomy/index.asciidoc ---------------------------------------------------------------------- diff --git a/docs/src/tutorials/gremlins-anatomy/index.asciidoc b/docs/src/tutorials/gremlins-anatomy/index.asciidoc index b36d881..998ff68 100644 --- a/docs/src/tutorials/gremlins-anatomy/index.asciidoc +++ b/docs/src/tutorials/gremlins-anatomy/index.asciidoc @@ -102,11 +102,11 @@ g.V(). by(label()).next() ---- -the `GraphTraversal` components are represented by the `has()`, `outE()` and `groupCount()` steps. The key to reading +the `GraphTraversal` components are represented by the `has()`, `outE()` and `groupCount()`-steps. The key to reading this Gremlin is to realize that the output of one step becomes the input to the next. Therefore, if you consider the start step of `V()` and realize that it returns vertices in the graph, the input to `has()` is going to be a `Vertex`. -The `has()` step is a filtering step and will take the vertices that are passed into it and block any that do not -meet the criteria it has specified. In this case, that means that the output of the `has()` step is vertices that have +The `has()`-step is a filtering step and will take the vertices that are passed into it and block any that do not +meet the criteria it has specified. In this case, that means that the output of the `has()`-step is vertices that have the label of "person" and the "name" property value of "josh" or "marko". image::gremlin-anatomy-filter.png[width=600] @@ -118,7 +118,7 @@ incoming "marko" and "josh" vertices and traverse their outgoing edges as the ou image::gremlin-anatomy-navigate.png[width=600] Now that it is clear that the output of `outE()` is an edge, you are aware of the input to `groupCount()` - edges. -The `groupCount()` step requires a bit more discussion of other Gremlin components and will thus be examined in the +The `groupCount()`-step requires a bit more discussion of other Gremlin components and will thus be examined in the following sections. At this point, it is simply worth noting that the output of `groupCount()` is a `Map` and if a Gremlin step followed it, the input to that step would therefore be a `Map`. @@ -130,7 +130,7 @@ remaining pieces. === Step Modulators It's been explained in several ways now that the output of one step becomes the input to the next, so surely the `Map` -produced by `groupCount()` will feed the `by()` step. As alluded to at the end of the previous section, that +produced by `groupCount()` will feed the `by()`-step. As alluded to at the end of the previous section, that expectation is not correct. Technically, `by()` is not a step. It is a step modulator. A step modulator modifies the behavior of the previous step. In this case, it is telling Gremlin how the key for the `groupCount()` should be determined. Or said another way in the context of the example, it answers this question: What do you want the "marko" @@ -148,7 +148,7 @@ methods, thus allowing `__.label()` to be referred to simply as `label()`. NOTE: In Java, the full package name for the `__` is `org.apache.tinkerpop.gremlin.process.traversal.dsl.graph`. -In the context of the example traversal, you can imagine Gremlin getting to the `groupCount()` step with a "marko" or +In the context of the example traversal, you can imagine Gremlin getting to the `groupCount()`-step with a "marko" or "josh" outgoing edge, checking the `by()` modulator to see "what to group by", and then putting edges into buckets by their `label()` and incrementing a counter on each bucket. @@ -160,7 +160,7 @@ The output is thus an edge label distribution for the outgoing edges of the "mar Terminal steps are different from the `GraphTraversal` steps in that terminal steps do not return a `GraphTraversal` instance, but instead return the result of the `GraphTraversal`. In the case of the example, `next()` is the terminal -step and it returns the `Map` constructed in the `groupCount()` step. Other examples of terminal steps include: +step and it returns the `Map` constructed in the `groupCount()`-step. Other examples of terminal steps include: `hasNext()`, `toList()`, and `iterate()`. Without terminal steps, you don't have a result. You only have a `GraphTraversal` @@ -169,7 +169,7 @@ link:http://tinkerpop.apache.org/docs/x.y.z/tutorials/the-gremlin-console/#resul === Expressions -It is worth backing up a moment to re-examine the `has()` step. Now that you have come to understand anonymous +It is worth backing up a moment to re-examine the `has()`-step. Now that you have come to understand anonymous traversals, it would be reasonable to make the assumption that the `within()` argument to `has()` falls into that category. It does not. The `within()` option is not a step either, but instead, something called an expression. An expression typically refers to anything not mentioned in the previously described Gremlin component categories that http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/dde73e42/docs/src/tutorials/the-gremlin-console/index.asciidoc ---------------------------------------------------------------------- diff --git a/docs/src/tutorials/the-gremlin-console/index.asciidoc b/docs/src/tutorials/the-gremlin-console/index.asciidoc index cc090d9..b34be6c 100644 --- a/docs/src/tutorials/the-gremlin-console/index.asciidoc +++ b/docs/src/tutorials/the-gremlin-console/index.asciidoc @@ -353,7 +353,7 @@ public final class Traversals { ---- Of course, this won't work and you will likely be left wondering why your unit test for "removeByName" is failing, but -the identical line of code in the console is doing what is expected. The `drop()` step is not some special form +the identical line of code in the console is doing what is expected. The `drop()`-step is not some special form of terminating step that iterates the traversal - it is just one more step that vertices will pass through. Outside of the console you must add `iterate()` as follows:
