GraphTraversal class object of TinkerPop. It takes data s from upstream and emits data e to downstream. Type c is called "walk type", a marker to describe the effect of the traversal.

GTraversal is NOT a Category. Because a GraphTraversal object keeps some context data, the starting (left-most) GraphTraversal object controls most of the behavior of entire composition of traversals and steps. This violates Category law.

Phantom type for GraphTraversal class. In greskell, we usually use GTraversal instead of Greskell GraphTraversal.

Types that can convert to GTraversal.

A chain of one or more Gremlin steps. Like GTraversal, type s is the input, type e is the output, and type c is a marker to describe the step.

Walk represents a chain of method calls such as .has(x).outE(). Because this is not a Gremlin (Groovy) expression, we use bare Walk, not Greskell Walk.

Walk is a Category. You can use functions from Control.Category to compose Walks. This is equivalent to making a chain of method calls in Gremlin.

Walk is not an Eq, because it's difficult to define true equality between Gremlin method calls. If we define it naively, it might have conflict with Category law.

GraphTraversalSource class object of TinkerPop. It is a factory object of GraphTraversals.

Class of phantom type markers to describe the effect of the walk/traversals.

WalkType for filtering steps.

A filtering step is a step that does filtering only. It takes input and emits some of them without any modification, reordering, traversal actions, or side-effects. Filtering decision must be solely based on each element.

A Walk w is Filter type iff:

(gSideEffect w == gIdentity) AND (gFilter w == w)

If Walks w1 and w2 are Filter type, then

gAnd [w1, w2] == w1 >>> w2 == w2 >>> w1

WalkType for steps without any side-effects. This includes transformations, reordring, injections and graph traversal actions.

A Walk w is Transform type iff:

gSideEffect w == gIdentity

Obviously, every Filter type Walks are also Transform type.

WalkType for steps that may have side-effects.

A side-effect here means manipulation of the "sideEffect" in Gremlin context (i.e. the stash of data kept in a Traversal object), as well as interaction with the world outside the Traversal object.

For example, the following steps (in Gremlin) all have side-effects.

.addE('label')
.aggregate('x')
.sideEffect(System.out.&println)
.map { some_variable += 1 }

Relation of WalkTypes where one includes the other. from can be lifted to to, because to is more powerful than from.

Relation of WalkTypes where the child walk c is split from the parent walk p.

When splitting, transformation effect done in the child walk is rolled back (canceled) in the parent walk.

Create GraphTraversalSource from a varible name in Gremlin

Apply the Walk to the GTraversal. In Gremlin, this means calling a chain of methods on the Traversal object.

Same as &. with arguments flipped.

Similar to <$>, but for $..

Since: 0.2.1.0

Similar to <*>, but for $..

Since: 0.2.1.0

.iterate method on GraphTraversal.

gIterate is not a Walk because it's usually used to terminate the method chain of Gremlin steps. The returned GTraversal outputs nothing, thus its end type is ().

Since: 1.1.0.0

Unsafely create GTraversal from the given raw Gremlin script.

Unsafely create a Walk that represents a single method call on a GraphTraversal.

Optionally modulate the main Walk with some modulating Walks.

.identity step.

.filter step that takes a traversal.

.cyclicPath step.

Since: 1.0.1.0

.simplePath step.

Since: 1.0.1.0

.is step of simple equality.

Since: 1.0.1.0

.is step with predicate P.

Since: 1.0.1.0

.has step with one argument.

.has step with two arguments.

.has step with two arguments and P type.

.hasLabel step.

.hasLabel step with P type. Supported since TinkerPop 3.2.7.

.hasId step.

.hasId step with P type. Supported since TinkerPop 3.2.7.

.hasKey step. The input type should be a VertexProperty.

.hasKey step with P type. Supported since TinkerPop 3.2.7.

.hasValue step. The input type should be a VertexProperty.

.hasValue step with P type. Supported since TinkerPop 3.2.7.

.and step.

.or step.

.not step.

.where step with P argument only.

If the ByProjection argument is Nothing, comparison is performed on the type a. You have to ensure that the comparator included in the LabeledP argument can handle the type a. Usually this means the type a should implement Java's Comparable interface (this is true for most Java classes).

If the ByProjection argument is given, comparison is performed on the projected values of type b. So, the type b should implement Java's Comparable interface.

Since: 1.2.0.0

.where step with the starting label and P arguments. See also gWhereP1.

Since: 1.2.0.0

.repeat step.

Since: 1.0.1.0

.times modulator before the .repeat step. It always returns Just.

Since: 1.0.1.0

.until modulator before the .repeat step. It always returns Just.

Since: 1.0.1.0

.until modulator after the .repeat step. It always returns Just.

Since: 1.0.1.0

.emit modulator without argument before the .repeat step. It always returns Just.

Since: 1.0.1.0

.emit modulator without argument after the .repeat step. It always returns Just.

Since: 1.0.1.0

.emit modulator with a sub-traversal argument before the .repeat step. It always returns Just.

Since: 1.0.1.0

.emit modulator with a sub-traversal argument after the .repeat step. It always returns Just.

Since: 1.0.1.0

.until or .times modulator step.

Type c is the WalkType of the parent .repeat step. Type s is the start (and end) type of the .repeat step.

Since: 1.0.1.0

.emit modulator step.

Type c is the WalkType of the parent .repeat step. Type s is the start (and end) type of the .repeat step.

Since: 1.0.1.0

Position of a step modulator relative to .repeat step.

Since: 1.0.1.0

A label that points to a loop created by .repeat step. It can be used by .loops step to specify the loop.

Since: 1.0.1.0

.local step.

Since: 1.0.1.0

.union step.

Since: 1.0.1.0

.coalesce step.

Like gFlatMap, gCoalesce always modifies path history.

Since: 1.1.0.0

.choose step with if-then-else style.

Since: 1.0.1.0

.barrier step.

Since: 1.0.1.0

.flatMap step.

.flatMap step is at least as powerful as Transform, even if the child walk is Filter type. This is because .flatMap step always modifies the path of the Traverser.

Since: 1.1.0.0

A pattern for .match step.

Since: 1.2.0.0

A convenient function to make a MatchPattern wrapped by Leaf.

Since: 1.2.0.0

Result of .match step.

Since: 1.2.0.0

.sideEffect step that takes a traversal.

Vertex anchor for gAddE. It corresponds to .from or .to step following an .addE step.

Type s is the input Vertex for the .addE step. Type e is the type of the anchor Vertex that the AddAnchor yields. So, .addE step creates an edge between s and e.

Since: 0.2.0.0

Projection from type s to type e used in .by step. You can also use gBy to construct ByProjection.

Data types that mean a projection from one type to another.

Comparison of type s used in .by step. You can also use gBy1 and gBy2 to construct ByComparator.

A ByProjection associated with an AsLabel. You can construct it by gByL.

Since: 1.0.0.0

.by step with 1 argument, used for projection.

.by step with 1 argument, used for comparison.

.by step with 2 arguments, used for comparison.

.by step associated with an AsLabel.

Since: 1.0.0.0