Various TraversalStrategy implementations inject barrier() instances to improve traversal performance. It is often helpful in debugging situations or in tweaking traversal performance activities that it may be necessary to prevent automated barrier() injection. Formerly, that involved removing LazyBarrierStrategy, RepeatUnrollStrategy, and PathRetractionStrategy as all three of those strategies had the potential to add a barrier(). While this approach would work, it may be hard to recall those three strategies easily and you may be removing optimizations that might have been useful in addition to the barrier().

In 3.4.11, it is only necessary to remove LazyBarrierStrategy. Doing so will disable barrier() additions in other strategies and as this is the new model of execution, it can be expected to work as the approach in the future even if other strategies attempt to add barrier() steps for some reason. Note of course that this rule only applies to TinkerPop-enabled strategies. It is possible that provider-specific strategies could add barrier()-steps and thus still require direct removal.

See: TINKERPOP-1994

In version 3.4.9, it became possible to set client-side read/write timeouts. Those timeouts were defaulted to thirty seconds which could put the client at odds with other timeout settings which could then cause unexpected failures. The client-side timeouts have now been defaulted to None leaving it to users to set the timeout themselves if they so desire. In this way, 3.4.10 has the same timeout behavior as 3.4.8 without any additional workarounds.

The timeouts can be configured as shown in the below example:

See: TINKERPOP-2505

One of the silent features of Gremlin is the ScriptTranslator. More specifically, the implementation of this interface which will convert a Traversal object (or Gremlin Bytecode) into a proper String representation that is syntactically correct for the implementation language.

Some Gremlin users may already be aware of the implementations for Groovy and Python from previous versions. These classes have largely been used for testing purposes, but users have found helpful use cases for them and they have now been promoted to gremlin-core from their original locations. The old versions in gremlin-groovy and gremlin-python have been deprecated. There have been some improvements to the GroovyTranslator such that the Gremlin generated will not match character for character with the deprecated version. There may also be some potential for the newer version in 3.4.9 to generate scripts that will not work in earlier versions. It is therefore best to use 3.4.9 translators within environments where 3.4.9 is uniformly supported. If older versions are in place, it may be better to continue use of the deprecated versions.

See: TINKERPOP-2461

The :bytecode command in the Gremlin console includes two new options: reset and config. Both options provide ways to better control the GraphSONMapper used internally by the command. The reset option will replace the current GraphSONMapper with a new one with some basic defaults: GraphSON 3.0 with extension and TinkerIoRegistry if present. The config option provides a way to specify a custom GraphSONMapper or additional configurations to the default one previously described.

See: TINKERPOP-2479

The withStrategies() configuration step accepts a variable number of TraversalStrategy instances. In Java, those instances are typically constructed with instance() if it is a singleton or by way of a builder pattern which provides a fluent, type safe method to create the object. For Groovy, which is highly applicable to those who use Gremlin scripts in their applications or work a lot within tools similar to the Gremlin Console, the builder syntax can work but doesn’t really match the nature of the Groovy language. Using a strategy in this script context would look something like:

While this method will still work, it is now possible to use a more succinct syntax for Groovy scripts:

The rules are straightforward. If a strategy can be instantiated with instance() as a singleton then use just the class name as a shortcut. Interestingly, many users try this syntax when they first get started and obviously fail. With the syntax present, they will have one less error to contend with in their early days of Gremlin. For strategies that take configurations, these strategies will use named arguments in the constructor where the names match the expected builder methods. This named argument syntax is common to Groovy and not something special to Gremlin - it is just now exposed for this purpose.

See: TINKERPOP-2466

The AnonymousTraversalSource was introduced in 3.3.5 and is most typically used for constructing remote TraversalSource instances, but it also provides a way to construct a TraversalSource from an embedded Graph instance:

The withGraph(Graph) method is now deprecated in favor the new withEmbedded(Graph) method that is more explicit about its intent:

This change is mostly applicable to JVM languages where embedded Graph instances are available. For Gremlin Language Variants not on the JVM, the withGraph(Graph) method has simply been deprecated and not replaced (with the preference to use withRemote() variants).

See: TINKERPOP-2413

Using SubgraphStrategy, PartitionStrategy and other TraversalStrategy implementations is now possible in Javascript.

See: TINKERPOP-2054

Gremlin Server now supports standard WebSocket compression (per RFC 7692). Both the Java and Python drivers support this functionality from the client’s perspective. Compression is enabled by default and should be backward compatible, thus allowing older versions of the driver to connect to newer versions of the server and vice versa. Using the compression-enabled drivers with a server that also supports that functionality will greatly reduce network IO requirements.

See: TINKERPOP-2441, TINKERPOP-2453

The Java Driver was designed with the idea that a Cluster instance would be created once and then used for the life of the application. As a result, the cost of setup and termination of that instance was typically sunk into the general startup and shutdown of the application itself. In some environments, where applications were short-lived, this cost was quite apparent and undesirable given that it might take several seconds to initialize and then a similar amount of time for proper shutdown.

In 3.4.9, the initialization and shutdown of the Cluster object has been improved dramatically, which should be especially helpful to those aforementioned ephemeral environments. The following micro-benchmark results demonstrate the difference in performance between 3.4.8 and 3.4.9:

See: TINKERPOP-2445

With Java it has been possible to pass per-request settings for both scripts and bytecode. While Javascript, Python, and .NET allowed this in various ways, it wasn’t quite as convenient as Java, nor was it well documented. In this release, the approach for making this sort of per-request configurations is now much more consistent across languages. We see this most evident in bytecode based requests:

Java

C#

Javascript

Python

Please see the new "Per Request Settings" sections for each language in the Gremlin Drivers and Variants section for information on how to send scripts with specific request configurations.

See: TINKERPOP-2296, TINKERPOP-2420, TINKERPOP-2421

The org.apache.tinkerpop.gremlin.server.util.CheckedGraphManager can be used instead of org.apache.tinkerpop.gremlin.server.util.DefaultGraphManager (in gremlin-server.yml to ensures that Gremlin Server fails to start if all graphs fails. This configuration option can be useful for a number of different situations (e.g. use CheckedGraphManager on a Kubernetes cluster to ensure that a pod will be restarted when it cannot properly handle requests.) As a final note, DefaultGraphManager is no longer final and thus can be extended.

See: TINKERPOP-2436

Lambda scripts can now be utilized in gremlin-javascript and follows roughly the same pattern as Python does:

See: TINKERPOP-2001

The Gremlin.NET driver now automatically tries to reconnect to a server when no open connection is available to submit a request. This should enable the driver to handle cases where the server is only temporarily unavailable or where the server has closed connections which some graph providers do when no requests were sent for some time.

See: TINKERPOP-2288

Gremlin Console now has the :cls command to clear the screen. This feature acts as an alternative to platform specific clear operations and provides a common way to perform that function.

TINKERPOP-2357

In 3.4.5 the equality of the Property object changed to allow language features like dedup() to work more consistently. An unnoticed side-effect of that change was that calling drop() on properties that had the same values would not properly remove all their instances. This problem affected edge and meta property instances but not the properties of vertices as their equality definitions had not changed.

This issue is now resolved with the side-effect being that the inclusion of drop() will disable LazyBarrierStrategy which prevents automatic bulking. In most common cases, the impact of that optimization loss should be minimal and could be added back manually with barrier() steps in the appropriate places.

See: TINKERPOP-2338

It is quite common to use the by(String) modulator when doing some for of selection operation where the String is the key to the value of the current Traverser, demonstrated as follows:

Of course, this approach usually only works when the current Traverser is an Element. If it is not an element, the error is swift and severe:

and while it is perhaps straightforward to see the problem in the above example, it is not always clear exactly where the mistake is. The above example is the typical misuse of by(String) and comes when one tries to treat a Map the same way as an Element (which is quite reasonable).

In 3.4.5, the issue of using by(String) on a Map and the error messaging have been resolved as follows:

See: TINKERPOP-2314

Previously, hasKey()-step and hasValue()-step only applied to vertex properties. In order to support more generalized scenarios, the behavior of these steps were modified to allow them to be applied to both edge properties and meta-properties.

The original behavior is demonstrated as follows:

The new behavior of hasKey() with edge property can be seen as:

Similar behavior of for hasKey() can be seen with meta-properties:

The new behavior for hasValue() with edge property is as follows:

and similarly with hasValue() for meta-properties:

TINKERPOP-1733

There was some inconsistency in terms of Property equality in earlier versions of Gremlin. Equality is now defined as follows: two properties are equal only if their key and value are equal, even if their parent elements are not equal. It makes sense when comparing properties regardless of parent elements to just focus on the property itself as it yields more uniform and concise results to reason about. The benefit of this change is that the behavior of property comparison and dedup()-step are predictable, and it will not affect the result if the property is detached from the parent element.

The old behavior can be shown using "The Crew" toy graph as follows:

The new more consistent behavior is demonstrated below:

See: TINKERPOP-2318

There is now support for GraphBinary in Python. As with Java, it remains a working but experimental format that is still under evaluation. This new serializer can be used by first ensuring that it is available on the server and then configuring the connection as follows:

TINKERPOP-2279

Since graph elements (i.e. Vertex, Edge, and VertexProperty) are returned from remote sources as references (i.e. without properties), one of the more common needs for Gremlin users is the ability to easily return a Map representation of the elements that they are querying. Typically, such transformations are handled by valueMap():

or by way of project():

While valueMap() works reasonably well for Vertex and VertexProperty transformations it does less well for Edge as it fails to include incident vertices:

This limitation forces a fairly verbose use of project() for what is a reasonably common requirement:

By introducing elementMap()-step, there is now a single step that covers the most common transformation requirements for all three graph elements:

See: TINKERPOP-2284, Reference Documentation

The store()-step and aggregate()-step do the same thing in different ways, where the former is lazy and the latter is eager in the side-effect collection of objects from the traversal. The different behaviors can be thought of as differing applications of Scope where global is eager and local is lazy. As a result, there is no need for both steps when one will do.

As of 3.4.3, store(String) is now deprecated in favor of aggregate(Scope, String) where the Scope should be set to local to ensure the same functionality as store(). Note that aggregate('x') is the same as aggregate(global,'x').

See: TINKERPOP-1553

Gryo is now deprecated as a serialization format for Gremlin Server, however, it is still configured as a default option in the sample configuration files packaged with the server. The preferred serialization option should now be GraphBinary. Note that Gremlin Console is now configured to use GraphBinary by default.

See: TINKERPOP-2250

In 3.4.0, the notion of RequestOptions were added so that users could have an easier way to configure settings on individual requests made through the Java driver. While that change provided a way to set those configurations for script based requests, it didn’t include options to make those settings in a Traversal submitted via Bytecode. In this release those settings become available via with() step on the TraversalSource as follows:

See: TINKERPOP-2211

The Gremlin Console timeout that is set by :remote config timeout x was client-side only in prior versions, which meant that if the console timeout was less than the server timeout the client would timeout but the server might still be processing the request. Similarly, a longer timeout on the console would not change the server and the timeout would occur sooner than expected. These discrepancies often led to confusion.

As of 3.4.0, the Java Driver API allowed for timeout settings to be more easily passed per request, so the console was modified for this current version to pass the console timeout for each remote submission thus yielding more consistent and intuitive behavior.

See: TINKERPOP-2203

In the initial release of sparql-gremlin it was only possible to execute a SPARQL query and have it translate to Gremlin. Therefore, it was only possible to write a query like this:

In this release, however, it is now possible to further process that result with Gremlin steps:

See: TINKERPOP-2171, Reference Documentation

The sparql-gremlin module is a SPARQL to Gremlin compiler, which allows SPARQL to be executed over any TinkerPop-enabled graph system.

See: TINKERPOP-1878, Reference Documentation

The Gremlin.NET driver now uses request pipelining. This allows connections to be reused for different requests in parallel which should lead to better utilization of connections. The ConnectionPool now also has a fixed size whereas it could previously create an unlimited number of connections. Each Connection can handle up to MaxInProcessPerConnection requests in parallel. If this limit is reached for all connections, then a NoConnectionAvailableException is thrown which makes this a breaking change.

These settings can be set as properties on the ConnectionPoolSettings instance that can be passed to the GremlinClient.

See: TINKERPOP-1774, TINKERPOP-1775, Reference Documentation

TinkerPop 3.4.0 adds a new index()-step, which allows users to transform simple collections into index collections or maps.

The valueMap() step now supports by and with modulation, which also led to the deprecation of valueMap(true) overloads.

In previous versions within() and without() performed strict number comparisons; that means these predicates did not only compare number values, but also the type. This was inconsistent with how other predicates (like eq, gt, etc.) work. All predicates will now ignore the number type and instead compare numbers only based on their value.

Old behavior:

New behavior:

See: TINKERPOP-2058

Gremlin Server has had some inconsistent behavior in the serialization of the results it returns. Remote traversals based on Gremlin bytecode always detach returned graph elements to "reference" (i.e. removes properties and only include the id and label), but scripts would detach graph elements and include the properties. For 3.4.0, TinkerPop introduces the ReferenceElementStrategy which can be configured on a GraphTraversalSource to always detach to "reference".

The packaged initialization scripts that come with Gremlin Server now pre-configure the sample graphs with this strategy to ensure that both scripts and bytecode based requests over any protocol (HTTP, websocket, etc) and serialization format all return a "reference". To revert to the old form, simply remove the strategy in the initialization script.

It is recommended that users choose to configure their GraphTraversalSource instances with ReferenceElementStrategy as working with "references" only is the recommended method for developing applications with TinkerPop. In the future, it is possible that ReferenceElementStrategy will be configured by default for all graphs on or off Gremlin Server, so it would be best to start utilizing it now and grooming existing Gremlin and related application code to account for it.

See: TINKERPOP-2075

Gremlin now supports simple text predicates on top of the existing P predicates. Both, the new TextP text predicates and the old P predicates, can be chained using and() and or().

See: TINKERPOP-2041

The infix notation of and() and or() now supports an arbitrary number of traversals and ConnectiveStrategy produces a traversal with proper AND and OR semantics.

Furthermore, previous versions failed to apply 3 or more and() steps using the infix notation, this is now fixed.

See: TINKERPOP-2029

GraphBinary is a new language agnostic, network serialization format designed to replace Gryo and GraphSON. At this time it is only available on the JVM, but support will be added for other languages in upcoming releases. The serializer has been configured in Gremlin Server’s packaged configuration files. The serializer can be configured using the Java driver as follows:

See: TINKERPOP-1942, IO Documentation

The Gremlin Server protocol allows for status attributes to be returned in responses. These attributes were typically for internal use, but were designed with extensibility in mind so that providers could place return their own attributes to calling clients. Unfortunately, unless the client was being used with protocol level requests (which wasn’t convenient) those attributes were essentially hidden from view. As of this version however, status attributes are fully retrievable for both successful requests and exceptions.

See: TINKERPOP-1913

This version of TinkerPop introduces the with()-step to Gremlin. It isn’t really a step but is instead a step modulator. This modulator allows the step it is modifying to accept configurations that can be used to alter the behavior of the step itself. A good example of its usage is shown with the revised syntax of the pageRank()-step which now uses with() to replace the old by() options:

A similar change was made for peerPressure()-step:

Note that the by() modulators still work, but should be considered deprecated and open for removal in a future release where breaking changes are allowed.

See: TINKERPOP-1975, Reference Documentation

Calculating the shortest path between vertices is a common graph use case. While the traversal to determine a shortest path can be expressed in Gremlin, this particular problem is common enough that the feature has been encapsulated into its own step, demonstrated as follows:

See: TINKERPOP-1990, Reference Documentation

In prior version of TinkerPop, it was recommended that the identification of Connected Component instances in a graph be computed by way of a reasonably complex bit of Gremlin that looked something like this:

The above approach had a number of drawbacks that included a large execution cost as well as incompatibilities in OLAP. To simplify usage of this commonly use graph algorithm, TinkerPop 3.4.0 introduces the connectedComponent() step which reduces the above operation to:

It is important to note that this step does require the use of a GraphComputer to work, as it utilizes a VertexProgram behind the scenes.

See: TINKERPOP-1967, Reference Documentation

There have been some important changes to IO operations for reading and writing graph data. The use of Graph.io() has been deprecated to further remove dependence on the Graph (Structure) API for users and to extend these basic operations to GLV users by making these features available as part of the Gremlin language.

It is now possible to simply use Gremlin:

While io()-step is still single-threaded for OLTP style loading, it can be utilized in conjunction with OLAP which internally uses CloneVertexProgram and therefore any graph InputFormat or OutputFormat can be configured in conjunction with this step for parallel loads of large datasets.

It is also worth noting that the io()-step may be overridden by graph providers to utilize their native bulk-loading features, so consult the documentation of the implementation being used to determine if there are any improved efficiencies there.

See: TINKERPOP-1996, Reference Documentation

The Java driver now allows for various options to be set on a per-request basis via new overloads to submit() that accept RequestOption instances. A good use-case for this feature is to set a per-request override to the scriptEvaluationTimeout so that it only applies to the current request.

See: TINKERPOP-1342

Previously min() and max() were only working for numeric values. This has been changed and these steps can now operate over any Comparable value. The common workaround was the combination of order().by() and limit() as shown here:

Any attempt to use min() or max() on non-numeric values lead to an exception:

With the changes in this release these kind of queries became a lot easier:

Traversals now support nesting of repeat() loops.

These can now be used to repeat another traversal while in a looped context, either inside the body of a repeat() or in its step modifiers (until() or emit()).

See: TINKERPOP-967

There were some minor modifications to how EventStrategy is constructed and what can be expected from events raised from the addition of new properties.

With respect to the change in terms of EventStrategy construction, the detach() builder method formerly took a Class as an argument and that Class was meant to be one of the various "detachment factories" or null. That approach was a bit confusing, so that signature has changed to detach(EventStrategy.Detachment) where the argument is a more handy enum of detachment options.

As for the changes related to events themselves, it is first worth noting that the previously deprecated vertexPropertyChanged(Vertex, Property, Object, Object…​) on MutationListener has been removed for what should have originally been the correct signature of vertexPropertyChanged(Vertex, VertexProperty, Object, Object…​). In prior versions when this method and its related edgePropertyChanged() and vertexPropertyPropertyChanged() were triggered by way of the addition of a new property a "fake" property was included with a null value for the "oldValue" argument to these methods (as it did not exist prior to this event). That was a bit awkward to reason about when dealing with that event. To make this easier, the event now raises with a KeyedVertexProperty or KeyedProperty instance, which only contains a property key and no value in them.

TINKERPOP-1831

The behavior of min(), max(), mean() and sum() has been modified to return no result if there’s no input. Previously these steps yielded the internal seed value:

These traversals will no longer emit a result. Note, that this also affects more complex scenarios, e.g. if these steps are used in by() modulators:

Since software vertices have no outgoing edges and thus no weight values to sum, software will no longer show up in the result. In order to get the same result as before, one would have to add a coalesce()-step:

See: TINKERPOP-1777

The order of select scopes has been changed to: maps, side-effects, paths. Previously the order was: side-effects, maps, paths - which made it almost impossible to select a specific map entry if a side-effect with the same name existed.

The following snippets illustrate the changed behavior:

Above is the old behavior; the second select("a") has no effect, it selects the side-effect a again, although one would expect to get the map entry a. What follows is the new behavior:

See: TINKERPOP-1522

In earlier versions of TinkerPop, BulkSet was coerced to a List for GraphSON which was convenient in that it didn’t add a new data type to support, but inconvenient in that it meant that certain process tests were not consistent in terms of how they ran and the benefits of the BulkSet were "lost" in that the "bulk" was being resolved server side. With the addition of BulkSet as a GraphSON type the "bulk" is now resolved on the client side by the language variant. How that resolution occurs depends upon the language variant. For Java, there is a BulkSet object which maintains that structure sent from the server. For the other variants, the BulkSet is deserialized to a List form which results in a much larger memory footprint than what is contained the BulkSet.

See: TINKERPOP-2111

Bindings were formerly created using a Python 2-tuple as a bit of syntactic sugar, but all other language variants used an explicit Bindings object which gremlin-python already had in place. To make all work variants behave consistently, the 2-tuple syntax has been removed in favor of the explicit Bindings.of() option.

See: TINKERPOP-2116

This section describes newly deprecated classes, methods, components and patterns of usage as well as which previously deprecated features have been officially removed or repurposed.

While TinkerPop doesn’t recommend the use of sessions for most use cases, it does remain a feature that is available and exposed on the server. As such, providing support in all Gremlin Language Variants for this feature is useful in ensuring a consistent implementation for all programming languages.

The maxWaitForSessionClose setting for the Java driver has been deprecated and in some sense replaced by the maxWaitForClose setting. The two settings perform different functions, but expect maxWaitForSessionClose to be removed in future versions. The maxWaitForClose performs a more useful function than maxWaitForSessionClose in the sense that it tells the driver how long it should wait for pending messages from the server before closing the connection. The maxWaitForSessionClose on the other hand is how long the driver should wait for the server to respond to a session close message (i.e. an actual response from the server). Waiting for that specific response to the session close message could result in the driver hanging on calls to Client.close() if there is a long run query running on the server and close message is stacked behind that in queue.

Future versions will remove support for that particular message and simply close the session when the connection is closed. As a result that setting will no longer be useful. The old setting is really only useful for connecting to older versions of the server prior to 3.3.11 that do not have the session shutdown hook bound to the close of the connection.

See: TINKERPOP-2336

Once a traversal has been executed (i.e. iterated) it’s internal state is such that it cannot be re-used:

To re-use a traversal it must be copied with clone() as follows:

The ability to clone() has been exclusive to Java and was a missing component of other supported languages like Python, Javascript and .NET. This feature has now been added for all the language variants making the ability to re-use traversals consistent in all ecosystems.

See: TINKERPOP-2315

Jython support in gremlin-python has been deprecated to focus on native Python 3.x support for 3.5.0 where Jython support will be wholly removed. This change does mean that TinkerPop will no longer support the ability to submit lambdas as native Python scripts. They will need to be submitted as Groovy and the library will be defaulted to do as such.

See: TINKERPOP-2322

ReservedKeysVerificationStrategy is a new VerificationStrategy that can be used to help prevent traversals from adding property keys that are protected. They may be protected as a result of the key being a reserved keyword of the underlying graph system or they key may simply violate some standard conventions.

TINKERPOP-2280

Gremlin Javascript now enables more robust error handling by way of a ResponseError which provides access to more information from the server. Specifically, it includes the statusMessage and statusCode which were formerly packed into the Error.message property, which meant that the error message string had to be parsed if there was a need to take a specific action based on that information. The ResponseError also includes the statusAttributes which is a Map object that will typically incorporate server exceptions and stackTrace keys, but could also include provider specific error information.

The original error messaging has remained unchanged and therefore users who were message parsing should not expect changes in behavior, however, future versions will eliminate the "overuse" of the Error.message property, so it is advised that users update their code to take advantage of the ResponseError features.

See: TINKERPOP-2285

Expect a NoHostAvailableException rather than a more generic TimeoutException if the Java driver is unable to connect to a Host. This sort of failure can occur in a number of different scenarios, but can often occur when there are configuration problems with authentication and SSL, preventing the connection to the Host to be established.

TINKERPOP-2132

The scriptEvaluationTimeout controls the length of time a request is processed by Gremlin Server (or at its core, the GremlinExecutor). Of course, with the introduction of bytecode-based requests many versions ago, this naming has failed to make complete sense in more recent times. Therefore, scriptEvaluationTimeout has been deprecated and replaced by evaluationTimeout. Both configurations are still respected, but it is advised that users switch to evaluationTimeout as scriptEvaluationTimeout will be removed in a later version.

Note that when configuring Gremlin Server’s evaluationTimeout that the scriptEvaluationTimeout should be set to -1 (the default) or else it will use that value in its initialization of the server and ignore the evaluationTimeout.

See: TINKERPOP-2213

Prior to this version, branch steps (in particular BranchStep and ChooseStep) could only handle constant values and Pick tokens. Starting in this version, these steps will also accept predicates and traversals as show in the example below.

See: TINKERPOP-1084

With GraphSON, the g:Date is meant to represent a millisecond-precision offset from the unix epoch, but earlier version of Gremlin Python were using the timezone of the local system to handle serialization and deserialization, thus resulting in incorrect conversion. This issue is now resolved. It may be necessary to remove workarounds that have been introduced to combat this problem.

See: TINKERPOP-2264

Gremlin-Javascript now supports withComputer() syntax, which means that it is now possible in Javascript to utilize Gremlin steps that require a GraphComputer to execute (e.g. pageRank() and peerPressure()).

See: TINKERPOP-2251

There is now greater consistency across Gremlin Language Variants with hasNext() support added to both JavaScript and .NET. Note that in .NET, the proper method name follows C# capitalization semantics and is referred to as HasNext().

See: TINKERPOP-1921

Traversal.getSideEffects() has been deprecated for purposes of external calls by end-users. While the method is still present TinkerPop no longer guarantees its existence in future versions or consistency of its behavior, especially for Gremlin Language Variants and remote traversal execution. If this method is currently in use to gather side-effect results after traversal execution, please change such code to use cap()-step. For example, code like this:

should be converted to something like:

TINKERPOP-2265

Prior TinkerPop 3.3.6 EventStrategy did not work with multi-properties. The EventStrategy behavior for single-valued properties has not changed; if a property is added to a multi-valued VertexProperty, then a VertexPropertyChangedEvent will be now be fired. The arguments passed to the event depend on the cardinality type.

See: TINKERPOP-2159

Gremlin DSL developers had to rely on monkey patching to build a Domain Specific Language in JavaScript. With this latest version, the process is a bit more elegant and largely handled by extending existing core classes of Gremlin-JavaScript which is a bit more in-line with other language variant patterns for DSL development.

See: TINKERPOP-2089, Reference Documentation

There are occasions where a traversal (or other evaluation) takes longer than expected to complete. Common examples of these situations typically include:

In earlier versions, the only option was to kill the Gremlin Console (typically with ctrl+c), but as of this version ctrl+c will be intercepted and attempt to interrupt whatever process is currently executing.

See TINKERPOP-2181

Gremlin Console included references to:

to provide some benchmarking and profiling tools for the Utilities Plugin. Neither project is well maintained at this point and given that TinkerPop has moved past the versions of Groovy that are supported by these tools it doesn’t make sense to retain the dependencies. Users who wish to continue to use these tools can obviously do so still by manually adding the dependencies to the Gremlin Console or with the following command:

and then import the appropriate classes and methods to use.

See: TINKERPOP-2182

The Gremlin Recipes documentation now has a new section which discusses anti-patterns in Gremlin. Its subsections detail commonly seen approaches to the Gremlin language which can lead to poorly written and/or under-performing traversals. The new Anti-Patterns Section can be found here.

See: TINKERPOP-2114

The AnonymousTraversalSource provides for a more unified syntax for TraversalSource construction by placing greater user emphasis on the creation of the source rather than the Graph it is connected to. It has a number of different static traversal() methods available and when imported as:

allows TraversalSource construction syntax such as:

Typically, this syntax is used for "remote" traversal construction for bytecode based requests, but has the option to bind a local Graph instance to it as well. It doesn’t save much typing to do so obviously, so it may not be best used in that situation. Python, Javascript and .NET have similar syntax.

See: TINKERPOP-2078

The Gremlin Console now has a new :bytecode command to help users work more directly with Gremlin bytecode. The command is more of a debugging tool than something that would be used for every day purposes. It is sometimes helpful to look at Gremlin bytecode directly and the process for viewing it in human readable format is not a single step process. It is also not immediately clear how to convert bytecode to a Gremlin string. The :bytecode command aims to help with both of these issues:

See: TINKERPOP-2050, Reference Documentation - Console Commands

The "class map" cache in Gremlin Server (specifically the GremlinGroovyScriptEngine) that holds compiled scripts is now fully configurable via the GroovyCompilerGremlinPlugin.classMapCacheSpecification.

See: TINKERPOP-2038, Reference Documentation - Cache Management

A new strategy named EarlyLimitStrategy was added. The strategy will try to find a better spot for any RangeStep, which is as early as possible in the traversal. If possible it will also merge multiple RangeStep`s into a single one by recalculating the range for the first step and removing the second. If it turns out that the merge of two steps won’t produce a valid range (an empty result), then the `EarlyLimitStrategy will remove the RangeStep instances and insert a NoneStep instead.

This strategy is particularly useful when a provider implementation generates the queries to the underlying database. By making sure that the ranges are applied as early as possible, we can ensure that the underlying database is only asked for the least amount of data necessary to continue the traversal evaluation.

The Order enum originally introduced incr for ascending order and decr for descending order. It’s not clear why they were named this way when common querying parlance would call for asc and desc for those respective cases. Note that incr and decr have not been removed - just deprecated and thus marked for future removal. Prefer asc and desc going forward when writing Gremlin and look to update existing code using the deprecated values.

See: TINKERPOP-1956

In Gremlin Server, it is best not to use the timedInterrupt option on GroovyCompilerGremlinPlugin because it can compete with the scriptEvaluationTimeout setting and produce a different error path. Simply rely on scriptEvaluationTimeout as it covers both script evaluation time and result iteration time.

See: TINKERPOP-1778

The Credential DSL has been modified to work as a standard Java-based Gremlin DSL. The now deprecated old approach used a "graph wrapping" style that was developed long before the recommended method for building DSLs was published. Under this new model, the DSL is initialized via traversal as follows:

See: TINKERPOP-1903, Reference Documentation - Security

Graph traversals that return a Set from Java are now coerced to a List in Python. This change ensures that Python results match Java results for the same traversal. It is possible to see this problem in prior versions of gremlin-python where a Set of numbers of different types are returned. In Java, a set of:

would be deserialized to the following in Python:

Now that the Java Set is coerced to a List in Gremin Python, the Java Set can be fully represented. Users who require a Set will need to manually convert their List to a Set.

See: TINKERPOP-1844

There was a bug in GraphSON 3.0 serialization that prevented proper handling of results contain Path object. As a result, traversals that used and returned results from the path()-step in Python would return unusable results, but did not actually cause an exception condition. This problem is now resolved.

See: TINKERPOP-1799

GraphTraversal.math(String) was added. This step provides scientific calculator capabilities to a Gremlin traversal.

See: TINKERPOP-1632

The from() and to()-steps of GraphTraversal have a Traversal<E,Vertex> overload. The E has been changed to ? in order to reduce < >-based coersion in strongly type Gremlin language variants.

See: TINKERPOP-1793

The GraphTraversal and GraphTraversalSource methods of addV() and addE() have been extended to support dynamic label determination upon element creation. Both these methods can take a Traversal<?, String> where the first String returned by the traversal is used as the label of the respective element.

See: TINKERPOP-1793

There were two major bugs in the way in which PageRank was being calculated in PageRankVertexProgram. First, teleportation energy was not being distributed correctly amongst the vertices at each round. Second, terminal vertices (i.e. vertices with no outgoing edges) did not have their full gathered energy distributed via teleportation.

For users upgrading, note that while the relative rank orders will remain "the same," the actual PageRank values will differ from prior TinkerPop versions.

Normalization preserved through computation:

Two other additions to PageRankVertexProgram were provided as well.

See: TINKERPOP-1783

While 3.3.0 released Gryo 3.0 and GraphSON 3.0 and these versions were defaulted in a number of places, it seems that some key defaults were missed. Specifically, calls to Graph.io(graphson()) and Graph.io(gryo()) were still using the old versions. The defaults have now been changed to ensure 3.0 is properly referenced in those cases.

See Neo4j’s 3.2 Upgrade FAQ for a complete guide on how to upgrade from the previous 2.3.3 version. Also note that many of the configuration settings have changed from neo4j 2x to 3x

In particular, these properties referenced in TinkerPop documentation and configuration were renamed:

TinkerPop has always packaged sample graphs with its zip distributions. As of 3.3.0, the distributions will only include Gryo 3.0, GraphSON 3.0 and GraphML (which is unversioned) files. Other versions are not included, but could obviously be generated using the IO API directly.

GraphTraversal.hasXXX(), where XXX is Id, Label, Key, Value, was faulty in that they relied on calling an intermediate method for flattening Object[] arguments and thus, yielding a non 1-to-1 correspondence between GraphTraversal and Bytecode. This has been remedied. Most users will not notice this change. Perhaps only some users that may use Java reflection over GraphTraversal might have a simple problem.

See: TINKERPOP-1520

Graphite and Ganglia are no longer packaged with the Gremlin Server distribution. They are considered optional dependencies and therefore must be installed manually by the user.

See: TINKERPOP-1550, Reference Documentation - Metrics

SelectStep and SelectOneStep (select()) are the only Scoping steps that default to Pop.mixed as their labeled path selection criteria. All other steps, like match(), where() and dedup(), use Pop.last. In order to better enable optimizations around total Pop.last traversals, the select()-steps now default to Pop.last. Most users will not notice a difference as it is rare for repeated labels to be used in practice. However, formal backwards compatibility is possible as outlined below.

Assuming that x is not a Pop argument:

If an explicit Pop argument is provided, then no changes are required.

See: TINKERPOP-1541

The optional()-step was previously implemented using ChooseStep. However, if the optional branch contained side-effects, then unexpected behaviors can emerge. Thus, a potential backwards compatibility issue arises if side-effects were being used in optional(). However, the behavior would be unpredictable so this backwards incompatibility is desirable.

See TINKERPOP-1506

It is no longer possible to intialize the Gremlin Console with a script without use of -e. In other words, prior versions allowed:

Such a command must now be written as:

See: TINKERPOP-1283, TINKERPOP-1651

GraphTraversal.valueMap(includeTokens,propertyKeys…​) now returns a Map<Object,E> to account for the presence of T.id or T.label if you pass true to it.

See: TINKERPOP-1483

The TinkerPop reference documentation has always mentioned that the gremlin-spark /lib directory needed to be added to HADOOP_GREMLIN_LIBS environment variable. In reality, that was not truly necessary. With Spark 1.x having gremlin-spark in HADOOP_GREMLIN_LIBS hasn’t been a problem, but Spark 2.0 introduces a check for duplicate jars on the path which will cause job initialization to fail. As a result, going forward with TinkerPop 3.3.0, the gremlin-spark lib directory should not be included in HADOOP_GREMLIN_LIBS.

The following deprecated classes, methods or fields have been removed in this version:

Please see the javadoc deprecation notes or upgrade documentation specific to when the deprecation took place to understand how to resolve this breaking change.

See: TINKERPOP-832, TINKERPOP-833, TINKERPOP-834, TINKERPOP-999, TINKERPOP-1010, TINKERPOP-1028, TINKERPOP-1040, TINKERPOP-1046, TINKERPOP-1049, TINKERPOP-1142, TINKERPOP-1169, TINKERPOP-1171, TINKERPOP-1275, TINKERPOP-1283, TINKERPOP-1289, TINKERPOP-1291, TINKERPOP-1420, TINKERPOP-1421, TINKERPOP-1465, TINKERPOP-1481, TINKERPOP-1526, TINKERPOP-1603, TINKERPOP-1612, TINKERPOP-1622, TINKERPOP-1651, TINKERPOP-1694, TINKERPOP-1700, TINKERPOP-1706, TINKERPOP-1721, TINKERPOP-1719, TINKERPOP-1720, TINKERPOP-880, TINKERPOP-1170, TINKERPOP-1729

gremlin-server.sh is now also an init script and can no longer be started without parameters. To start it in the foreground with defaults like previous usage, please use the console parameter. Also, gremlin-server.sh will continue to start in the foreground when provided a yaml configuration file.

How to install as a service has been added to the Reference Documentation - As A Service.

The switch name has changed for installing dependencies. -i has been deprecated and replaced by install.

See: TINKERPOP-980, Reference Documentation - Server Configuration.

The userMapperFromGraph serialization configuration option was used to allow the IO configurations of a specific graph to be assigned to a specific serializer. This feature has been removed completely now. Please use the ioRegistries configuration option to add one or more specific Graph serialization capabilities to a serializer.

see: TINKERPOP-1699

The switch name has changed for installing dependencies. -i has been deprecated and replaced by install.

Historically, SparkGraphComputer has used GryoSerializer to handle the serialization of objects in Spark. The reason this exists is because TinkerPop uses a shaded version of Kryo and thus, couldn’t use the standard KryoSerializer-model provided by Spark. However, a "shim model" was created which allows for the shaded and unshaded versions of Kryo to interact with one another. To this end, KryoSerializer can now be used with a GryoRegistrator. The properties file for a SparkGraphComputer now looks as follows:

If the old GryoSerializer model is desired, then the properties file should simply look as before:

See: TINKERPOP-1389

The API for the script provided to a ScriptInputFormat has changed slightly. The signature for parse(line, factory) is now simply parse(line). The inclusion of factory was deprecated in 3.1.2. Instead of using the {{factory}} to get the {{StarGraph}} there is a {{graph}} variable in the glocal context of the script. Simply use that directly in the script.

See: TINKERPOP-1137, Reference Documentation - Script I/O Format

The Gremlin Javascript Driver now supports SASL Plain Text authentication against a Gremlin Server.

See: TINKERPOP-1977, Reference Documentation - Gremlin Javascript

TinkerPop improves its security posture by removing insecure defaults and adding forward-looking standards support.

Gremlin Server no longer supports automatically creating self-signed certificates. Self-signed certificates can still be created manually outside of Gremlin Server. If ssl is enabled, a key store must be configured.

Cluster client no longer trusts all certs by default as this is an insecure configuration. Instead, if no trust store is configured, Cluster will use the default CA certs. To revert to the previous behavior and accept all certs, it must be explicitly configured.

This release introduces JKS and PKCS12 support. JKS is the legacy Java Key Store. PKCS12 has better cross-platform support and is gaining in adoption. Be aware that JKS is the default on Java 8. Java 9 and higher use PKCS12 as the default. Both Java keytool and OpenSSL tools can create, read, update PKCS12 files.

Other new features include specifying SSL protocols and cipher suites. The packaged *-secure.yaml files now restrict the protocol to TLSv1.2 by default.

PEM-based configurations are deprecated and may be removed in a future release.

See also Connecting via Java Configuration, Gremlin Server Configuration.

TINKERPOP-2022 TINKERPOP-2023

TinkerPop has provided some general methods for importing and exporting data, but more and more graph providers are producing their own bulk import/export facilities and they are more efficient and easier to use than TinkerPop’s methods. As a result, TinkerPop will now refer users to the bulk import/export features of individual graph providers and as such, has deprecated BulkLoaderVertexProgram as of this release.

As part of this change, the BulkDumperVertexProgram has been renamed to CloneVertexProgram with the former being deprecated. CloneVertexProgram is more aptly named, as it essentially copies a graph from a graph InputFormat to a graph OutputFormat.

TINKERPOP-1985

Docker images are now available on Docker Hub for Gremlin Console and Gremlin Server.

See: TINKERPOP-1897, Reference Documentation - Gremlin Console, Reference Documentation - Gremlin Server,

In Gremlin Server, it is best not to use 'TimedInterruptCustomizerProvider' because it can compete with the 'scriptEvaluationTimeout' setting and produce a different error path. Simply rely on 'scriptEvaluationTimeout' as it covers both script evaluation time and result iteration time.

See: TINKERPOP-1778

The Grateful Dead dataset has been with TinkerPop since the early days of 1.x. It has always been available as a packaged dataset that needed to be loaded through the various IO options available, while other toy graphs had the benefit of TinkerFactory to help get them bootstrapped. For 3.2.10, Grateful Dead is now more conveniently loaded via that same method as the other toy graphs with TinkerFactory.createGratefulDead().

Gremlin Javascript can now submit script, with optional bindings, using the Client class:

and also allows translation of bytecode steps into script:

It was realized quite shortly after release of 3.2.8 that there was a bug in construction of Lambda instances:

The problem was related to a bug in Groovy 2.4.14 and was fixed in 2.4.15.

See: TINKERPOP-1953

Gremlin Server now has two new settings: idleConnectionTimeout and keepAliveInterval. The keepAliveInterval tells Gremlin Server how long it should wait between writes to a client before it issues a "ping" to that client to see if it is still present. The idleConnectionTimeout represents how long Gremlin Server should wait between requests from a client before it closes the connection on the server side. By default, these two configurations are set to zero, meaning that they are both disabled.

This change should help to alleviate issues where connections are left open on the server longer than they should be by clients that might mysteriously disappear without properly closing their connections.

See: TINKERPOP-1726

Gremlin.Net now has a Lambda class that can be used to construct Groovy or Java lambdas which will be evaluated on the server.

See: TINKERPOP-1854, Reference Documentation - Gremlin.Net - The Lambda Solution.

The various Gremlin tokens (e.g. T, Order, Operator, etc.) that were implemented as Enums before in Gremlin.Net are now implemented as classes. This mainly allows them to implement interfaces which their Java counterparts already did. T for example now implements the new interface IFunction which simply mirrors its Java counterpart Function. Steps that expect objects for those interfaces as arguments now explicitly use the interface. Before, they used just object as the type for these arguments which made it hard for users to know what kind of object they can use. However, usage of these tokens themselves shouldn’t change at all (e.g. T.Id is still T.Id).

See: TINKERPOP-1901

Gremlin.Net used two classes for traversal predicates: P and TraversalPredicate. Steps that worked with traversal predicates expected objects of type TraversalPredicate, but they were constructed from the P class (e.g. P.Gt(1) returned a TraversalPredicate). Merging these two classes into the P class should avoid unnecessary confusion. Most users should not notice this change as predicates can still be constructed exactly as before, e.g., P.Gt(1).And(P.Lt(3)) still works without any modifications. Only users that implemented their own predicates and used TraversalPredicate as the base class need to change their implementation to now use P as the new base class.

See: TINKERPOP-1919

With the addition of UUID, Date, and Timestamp, Gremlin-Python now implements serializers for all core GraphSON types. Users that were using other types to represent this data can now use the Python classes datetime.datetime and`uuid.UUID` in GLV traversals. Since Python does not support a native Timestamp object, Gremlin-Python now offers a dummy class Timestamp, which allows users to wrap a float and submit it to the Gremlin Server as a Timestamp GraphSON type. Timestamp can be found in gremlin_python.statics.

See: TINKERPOP-1807

EventStrategy forced detachment of mutated elements prior to raising them in events. While this was a desired outcome, it may not have always fit every use case. For example, a user may have wanted a reference element or the actual element itself. As a result, EventStrategy has changed to allow it to be constructed with a detach() option, where it is possible to specify any of the following: null for no detachment, DetachedFactory for the original behavior, and ReferenceFactory for detachment that returns reference elements.

See: TINKERPOP-1829

As Gremlin Language Variants (GLVs) expand their usage and use of withRemote() becomes more common, the need to mock the "remote" in unit tests increases. To simplify mocking in Java, the new EmbeddedRemoteConnection provides a simple way to provide a "remote" that is actually local to the same JVM.

See: TINKERPOP-1756

Prior to this version, the Java annotation processor for Gremlin DSLs has tried to infer the appropriate type specifications when generating anonymous methods. It largely performed this inference on simple conventions in the DSL method’s template specification and there were times where it would fail. For example, a method like this:

would generate an anonymous method like:

and, of course, generate a compile error and E was not recognized as a symbol. The preferred generation would likely be:

To remedy this situation, a new annotation has been added which allows the user to control the type specifications more directly providing a way to avoid/override the inference system:

which will then generate:

See: TINKERPOP-1791

The :remote connect command can now take a pre-defined Cluster object as its argument as opposed to a YAML configuration file.

See: TINKERPOP-1787

There was limited support for "timeouts" with remote traversals (i.e. those traversals executed using the withRemote() option) prior to 3.2.7. Remote traversals will now interrupt on the server using the scriptEvaluationTimeout setting in the same way that normal script evaluations would. As a reminder, interruptions for traversals are always considered "attempts to interrupt" and may not always succeed (a graph database implementation might not respect the interruption, for example).

See: TINKERPOP-1770

The match()-step has been generalized to support the local scoping of all barrier steps, not just reducing barrier steps. Previously, the order().limit() clause would have worked globally yielding:

However, now, order() (and all other barriers) are treated as local computations to the pattern and thus, the result set is:

Note that this is not that intense of a breaking change as all of the reducing barriers behaved in this manner previously. This includes steps like count(), min(), max(), sum(), group(), groupCount(), etc. This update has now generalized this behavior to all barriers and thus, adds aggregate(), dedup(), range(), limit(), tail(), and order() to the list of locally computed clauses.

See: TINKERPOP-1764

In gremlin-test there is a new GraphHelper class that has a cloneElements() method. It will clone elements from the first graph to the second - GraphHelper.cloneElements(Graph original, Graph clone). This helper method is primarily intended for use in tests.

The MutationListener has a method called vertexPropertyChanged which gathered callbacks when a property on a vertex was modified. The method had an incorrect signature though using Property instead of VertexProperty. The old method that used Property has now been deprecated and a new method added that uses VertexProperty. This new method has a default implementation that calls the old method, so this change should not cause breaks in compilation on upgrade. Internally, TinkerPop no longer calls the old method except by way of that proxy. Users who have MutationListener implementations can simply add the new method and override its behavior. The old method can thus be ignored completely.

See: TINKERPOP-1798

Prior to this release, there was no semantic check to determine whether a self-edge (e.g. e[1][2-self→2]) would be returned twice on a BOTH. The semantics have been specified now in the test suite where the edge should be returned twice as it is both an incoming edge and an outgoing edge.

See: TINKERPOP-1821

The userMapperFromGraph configuration option for the Gremlin Server serializers has been deprecated. Change configuration files to use the ioRegistries option instead. The ioRegistries option is not a new feature, but it has not been promoted as the primary way to add IoRegistry instances to serializers.

See: TINKERPOP-1694

The WsAndHttpChannelizer has been added to allow for processing both WebSocket and HTTP requests on the same port and gremlin server. The SaslAndHttpBasicAuthenticationHandler has also been added to service authentication for both protocols in conjunction with the SimpleAuthenticator.

See: TINKERPOP-915

ReferenceVertex.label() was hard coded to return EMPTY_STRING. At some point, ReferenceElements were suppose to return labels and ReferenceVertex was never updated as such. Note that ReferenceEdge and ReferenceVertexProperty work as expected. However, given a general change at ReferenceElement, the Gryo serialization of ReferenceXXX is different. If the vertex does not have a label Vertex.DEFAULT_LABEL is assumed.

See: TINKERPOP-1789

It has always been possible to construct Domain Specific Languages (DSLs) with Gremlin, but the approach has required a somewhat deep understanding of the TinkerPop code base and it is not something that has had a recommended method for implementation. With this release, TinkerPop simplifies DSL development and provides the best practices for their implementation.

See: TINKERPOP-786, Reference Documentation

Serialization of Path with GraphSON was inconsistent with Gryo in that all the properties on any elements of the Path were being included. With Gryo that, correctly, was not happening as that could be extraordinarily expensive. GraphSON serialization has now been modified to properly not include properties. That change can cause breaks in application code if that application code tries to access properties on elements in a Path as they will no longer be there. Applications that require the properties will need to alter their Gremlin to better restrict the data they want to retrieve.

See: TINKERPOP-1676

The server settings previously used authentication.className to set an authenticator for the the two provided authentication handler and channelizer classes to use. This has been deprecated in favor of authentication.authenticator. A class that extends AbstractAuthenticationHandler may also now be provided as authentication.authenticationHandler to be used in either of the provided channelizer classes to handle the provided authenticator

See: TINKERPOP-1657

It was learned that compilation for scripts with large numbers of parameters is more expensive than those with less parameters. It therefore becomes possible to make some mistakes with how Gremlin Server is used. A new setting on the StandardOpProcessor and SessionOpProcessor called maxParameters controls the number of parameters that can be passed in on a request. This setting is defaulted to sixteen.

Users upgrading to this version may notice errors in their applications if they use more than sixteen parameters. To fix this problem simply reconfigure Gremlin Server with a configuration as follows:

The above configuration allows sixty-four parameters to be passed on each request.

See: TINKERPOP-1663

The GremlinScriptEngine has a number of new metrics about its cache size and script compilation times which should be helpful in understanding usage problems. As GremlinScriptEngine instances are used in Gremlin Server these metrics are naturally exposed as part of the standard metrics set. Note that metrics are captured for both sessionless requests as well as for each individual session that is opened.

See: TINKERPOP-1644

Additional information on error responses from Gremlin Server should help make debugging errors easier. Error responses now have both the exception hierarchy and the stack trace that was generated on the server. In this way, receiving an error on a client doesn’t mean having to rifle through Gremlin Server logs to try to find the associated error.

This change has been applied to all Gremlin Server protocols. For the binary protocol and the Java driver this change means that the ResponseException thrown from calls to submit() requests to the server now have the following methods:

The HTTP protocol has also been updated and returns both exceptions and stackTrace fields in the response:

Note that the Exception-Class which was added in a previous version has been deprecated and replaced by these new fields.

See: TINKERPOP-1044

The gremlin.sh command has two flags, -i and -e, which are used to pass a script and arguments into the Gremlin Console for execution. Those flags now allow for passing multiple scripts and related arguments to be supplied which can yield greater flexibility in automation tasks.

See: TINKERPOP-1653

It is now possible to extract analyze sub-paths using from() and to() modulations with respective, path-based steps. Likewise, simplePath() and cyclicPath() now support, along with from() and to(), by()-modulation so the cyclicity is determined by projections of the path data. This extension is fully backwards compatible.

See: TINKERPOP-1387

Gremlin Server previously implemented its own final GraphManager class. Now, the GraphManager has been changed to an interface, and users can supply their own GraphManager implementations in their YAML. The previous GraphManager class was meant be used by classes internal to Gremlin Server, but it was public so if it was used for some reason by users then then a compile error can be expected. To correct this problem, which will likely manifest as a compile error when trying to create a new GraphManager() instance, simply change the code to new DefaultGraphManager(Settings).

In addition to the change mentioned above, several methods on GraphManager were deprecated:

See: TINKERPOP-1438

Gremlin-Python now offers a more complete driver implementation that uses connection pooling and the Python concurrent.futures module to provide asynchronous I/0 using threading. The default underlying WebSocket client implementation is still provided by Tornado, but it is trivial to plug in another client by defining the Transport interface.

Using the DriverRemoteConnection class is the exact same as in previous versions; however, DriverRemoteConnection now uses the new Client class to submit messages to the server.

The Client class implementation/interface is based on the Java Driver, with some restrictions. Most notably, Gremlin-Python does not yet implement the Cluster class. Instead, Client is instantiated directly. Usage is as follows:

See: TINKERPOP-1599

A TinkerGraph deserialized from Gryo or GraphSON is now configured with multi-properties enabled. This change allows TinkerGraphs returned from Gremlin Server to properly return multi-properties, which was a problem seen when subgraphing a graph that contained properties with a setting other than Cardinality.single.

This change could be considered breaking in the odd chance that a TinkerGraph returned from Gremlin Server was later mutated, because calls to property(k,v) would default to Cardinality.list instead of Cardinality.single. In the event that this is a problem, simple change calls to property(k,v) to property(Cardinality.single,k,v) and explicitly set the Cardinality.

See: TINKERPOP-1587

The Traversal API now has a new promise() method. These methods return a promise in the form of a CompleteableFuture. Usage is as follows:

At this time, this method is only used for traversals that are configured using withRemote().

See: TINKERPOP-1490

Gremlin’s choose()-step supports if/then/else-semantics. Thus, to effect if/then-semantics, identity() was required. Thus, the following two traversals below are equivalent with the later being possible in this release.

See: TINKERPOP-1508

Previously, a call to Traversal.next() that did not have a result would throw a FastNoSuchElementException. This has been changed to a regular NoSuchElementException that includes the stack trace. Code that explicitly catches FastNoSuchElementException should be converted to check for the more general class of NoSuchElementException.

See: TINKERPOP-1330

ScriptEngine and GremlinPlugin infrastructure has been moved from gremlin-groovy to gremlin-core to allow for better re-use across different Gremlin Language Variants. At this point, this change is non-breaking as it was implemented through deprecation.

The basic concept of a ScriptEngine has been replaced by the notion of a GremlinScriptEngine (i.e. a "ScriptEngine" that is specifically tuned for executing Gremlin-related scripts). "ScriptEngine" infrastructure has been developed to help support this new interface, specifically GremlinScriptEngineFactory and GremlinScriptEngineManager. Prefer use of this infrastructure when instantiating a GremlinScriptEngine rather than trying to instantiate directly.

For example, rather than instantiate a GremlinGroovyScriptEngine with the constructor:

prefer to instantiate it as follows:

Related to the addition of GremlinScriptEngine, org.apache.tinkerpop.gremlin.groovy.plugin.GremlinPlugin in gremlin-groovy has been deprecated and then replaced by org.apache.tinkerpop.gremlin.jsr223.GremlinPlugin. The new version of GremlinPlugin is similar but does carry some new methods to implement that involves the new Customizer interface. The Customizer interface is the way in which GremlinScriptEngine instance can be configured with imports, initialization scripts, compiler options, etc.

Note that a GremlinPlugin can be applied to a GremlinScriptEngine by adding it to the GremlinScriptEngineManager that creates it.

All of this new infrastructure is currently optional on the 3.2.x line of code. More detailed documentation will for these changes will be supplied as part of 3.3.0 when these features become mandatory and the deprecated code is removed.

See: TINKERPOP-1562

Added new server configuration option ssl.needClientAuth.

See: TINKERPOP-1602

In 3.2.2, the Gremlin Console introduced a setting called empty.result.indicator, which controlled the output that was presented when no result was returned. For consistency, this setting has been renamed to result.indicator.null and can be set as follows:

See: TINKERPOP-1409

The Java Driver now has a keepAliveInterval setting, which controls the amount of time in milliseconds it should wait on an inactive connection before it sends a message to the server to keep the connection maintained. This should help environments that use a load balancer in front of Gremlin Server by ensuring connections are actively maintained even during periods of inactivity.

See: TINKERPOP-1249

It is now possible to use by() with where() predicate-based steps. Previously, without using match(), if you wanted to know who was older than their friend, the following traversal would be used.

Now, with where().by() support, the above traversal can be expressed more succinctly and more naturally as follows.

See: TINKERPOP-1330

The TinkerPop 3.2.2 release unintentionally introduced a breaking change for some has() method overloads. In particular the behavior for single item array arguments was changed:

Prior this change single item arrays were treated like there was only that single item:

TinkerPop 3.2.3 fixes this misbehavior and all has() method overloads behave like before, except that they no longer support no arguments.

The reconnectInitialDelay setting on the Cluster builder has been deprecated. It no longer serves any purpose. The value for the "initial delay" now comes from reconnectInterval (there are no longer two separate settings to control).

See: TINKERPOP-1460

TraversalSource now implements AutoCloseable, which means that the close() method is now available. This new method is important in cases where withRemote() is used, as withRemote() can open "expensive" resources that need to be released.

In the case of TinkerPop’s DriverRemoteConnection, close() will destroy the Client instance that is created internally by withRemote() as shown below:

Note that the withRemote() method will call close() on a RemoteConnection passed directly to it as well, so there is no need to do that manually.

See: TINKERPOP-790

There is new reference documentation for the various IO formats. The documentation provides more details and samples that should be helpful to users and providers who intend to work directly with the TinkerPop supported serialization formats: GraphML, GraphSON and Gryo.

See: IO Reference Documentation

GraphSON 2.0 has been introduced to improve and normalize the format of types embedded in GraphSON.

See: TINKERPOP-1274, Reference Documentation - GraphSON 2.0.

There were a number of changes to the Log4j dependencies in the various modules. Log4j was formerly included as part of the slf4j-log4j12 in gremlin-core, however that "forced" use of Log4j as a logger implementation when that really wasn’t necessary or desired. If a project depended on gremlin-core or other TinkerPop project to get its Log4j implementation then those applications will need to now include the dependency themselves directly.

Note that Gremlin Server and Gremlin Console explicitly package Log4j in their respective binary distributions.

See: TINKERPOP-1151

The gremlinPool setting in Gremlin Server is now defaulted to zero. When set to zero, Gremlin Server will use the value provided by Runtime.availableProcessors() to set the pool size. Note that the packaged YAML files no longer contain the thread pool settings as all are now driven by sensible defaults. Obviously these values can be added and overridden as needed.

See: TINKERPOP-1373

The Gremlin Console can now have its text colorized. For example, you can set the color of the Gremlin ascii art to the more natural color of green by using the :set command:

It is also possible to colorize results, like vertices, edges, and other common returns. Please see the reference documentation for more details on all the settings.

The console also now includes better multi-line support:

This is a nice feature in that it can help you understand if a line is incomplete and unevaluated.

See: TINKERPOP-1285, TINKERPOP-1037, Reference Documentation - Console Preferences

This is only a rename to clarify the design of the API. There is no change to the API itself.

The Gephi Plugin has been updated to support Gephi 0.9.x. Please upgrade to this latest version to use the Gephi Plugin for Gremlin Console.

See: TINKERPOP-1297

It is now possible to override existing serializers with calls to addCustom on the GryoMapper builder. This option allows complete control over the serializers used by Gryo. Of course, this also makes it possible to produce completely non-compliant Gryo files. This feature should be used with caution.

TraversalVertexProgram always maintained a HALTED_TRAVERSERS TraverserSet for each vertex throughout the life of the OLAP computation. However, if there are no halted traversers in the set, then there is no point in keeping that compute property around as without it, time and space can be saved. Users that have VertexPrograms that are chained off of TraversalVertexProgram and have previously assumed that HALTED_TRAVERSERS always exists at each vertex, should no longer assume that.

Traversals now better respect calls to Thread.interrupt(), which mean that a running Traversal can now be cancelled. There are some limitations that remain, but most OLTP-based traversals should cancel without issue. OLAP-based traversals for Spark will also cancel and clean up running jobs in Spark itself. Mileage may vary on other process implementations and it is possible that graph providers could potentially write custom step implementations that prevent interruption. If it is found that there are configurations or specific traversals that do not respect interruption, please mention them on the mailing list.

See: TINKERPOP-946

Gremlin Console had several methods for executing scripts from file at the start-up of bin/gremlin.sh. There were two options:

Changes in this version of TinkerPop have added much more flexibility here and only a minor breaking change should be considered when using this version. First of all, recognize that hese two lines are currently equivalent:

but users should start to explicitly specify the -i flag as TinkerPop will eventually remove the old syntax. Despite the one used beware of the fact that neither will close the console on script failure anymore. In that sense, this behavior represents a breaking change to consider. To ensure the console closes on failure or success, a script will have to use the -e option.

The console also has a number of new features in addition to -e and -i:

See: TINKERPOP-1268, TINKERPOP-1155, TINKERPOP-1156, TINKERPOP-1157, Reference Documentation - Interactive Mode, Reference Documentation - Execution Mode

The HadoopGremlinPlugin defines two variables: hdfs and fs. The first is a reference to the HDFS FileSystemStorage and the latter is a reference to the local FileSystemStorage. Prior to 3.2.x, fs was called local. However, there was a variable name conflict with Scope.local. As such local is now fs. This issue existed prior to 3.2.x, but was not realized until this release. Finally, this only effects Gremlin Console users.

Note that gremlin.hadoop.graphInputFormat, gremlin.hadoop.graphOutputFormat, gremlin.spark.graphInputRDD, and gremlin.spark.graphOuputRDD have all been deprecated. Using them still works, but moving forward, users only need to leverage gremlin.hadoop.graphReader and gremlin.hadoop.graphWriter. An example properties file snippet is provided below.

See: TINKERPOP-1082, TINKERPOP-1222

There were changes to TraversalSideEffect both at the semantic level and at the API level. Users that have traversals of the form sideEffect{…​} that leverage global side-effects should read the following carefully. If the user’s traversals do not use lambda-based side-effect steps (e.g. groupCount("m")), then the changes below will not effect them. Moreover, if user’s traversal only uses sideEffect{…​} with closure (non-TraversalSideEffect) data references, then the changes below will not effect them. If the user’s traversal uses sideEffects in OLTP only, the changes below will not effect them. Finally, providers should not be effected by the changes save any tests cases.

The profile()-step has been refactored into 2 steps — ProfileStep and ProfileSideEffectStep. Users who previously used the profile() in conjunction with cap(TraversalMetrics.METRICS_KEY) can now simply omit the cap step. Users who retrieved TraversalMetrics from the side-effects after iteration can still do so, but will need to specify a side-effect key when using the profile(). For example, profile("myMetrics").

See: TINKERPOP-958

There was a bug in BranchStep that also rears itself in subclass steps such as UnionStep and ChooseStep. For traversals with branches that have barriers (e.g. count(), max(), groupCount(), etc.), the traversal needs to be updated. For instance, if a traversal is of the form g.V().union(out().count(),both().count()), the result is now different (the bug fix yields a different output). In order to yield the same result, the traversal should be rewritten as g.V().local(union(out().count(),both().count())). Note that if a branch does not have a barrier, then no changes are required. For instance, g.V().union(out(),both()) does not need to be updated. Moreover, if the user’s traversal already used the local()-form, then no change are required either.

See: TINKERPOP-1188

Users that have custom VertexProgram implementations will need to change their implementations to support the new VertexComputeKey and MemoryComputeKey classes. In the VertexPrograms provided by TinkerPop, these changes were trivial, taking less than 5 minutes to make all the requisite updates.

An example migration looks as follows. What might currently look like:

Should now look like:

A similar patterns should also be used for VertexProgram.getVertexComputeKeys().

See: TINKERPOP-1162

The MapReduce-based steps in TraversalVertexProgram have been removed and replaced using a new Memory-reduction model. MapReduce jobs always created a persistence footprint, e.g. in HDFS. Memory data was never persisted to HDFS. As such, there will be no data on the disk that is accessible. For instance, there is no more ~reducing, ~traversers, and specially named side-effects such as m from a groupCount('m'). The data is still accessible via ComputerResult.memory(), it simply does not have a corresponding on-disk representation.

RemoteGraph is a lightweight Graph implementation that acts as a proxy for sending traversals to Gremlin Server for remote execution. It is an interesting alternative to the other methods for connecting to Gremlin Server in that all other methods involved construction of a String representation of the Traversal which is then submitted as a script to Gremlin Server (via driver or HTTP).

Note that g.V().valueMap(true) is executing in Gremlin Server and not locally in the console.

See: TINKERPOP-575, Reference Documentation - Remote Graph

There were some inconsistencies in the GraphML format supported in TinkerPop 2.x. These issues were corrected on the initial release of TinkerPop 3.0.0, but as a result, attempting to read GraphML from 2.x will end with an error. A newly added XSLT file in gremlin-core, called tp2-to-tp3-graphml.xslt, transforms 2.x GraphML into 3.x GraphML, making it possible easily read in legacy GraphML through a 3.x GraphMLReader.

See: TINKERPOP-1608

There were a few problems noted around the close() of Cluster and Client instances, including issues that presented as system hangs. These issues have been resolved, however, it is worth noting that an unchecked exception that was thrown under a certain situation has changed as part of the bug fixes. When submitting an in-session request on a Client that was closed (or closing) an IllegalStateException is thrown. This replaces older functionality that threw a ConnectionException and relied logic far deeper in the driver to produce that error and had the potential to open additional resources despite the intention of the user to "close".

See: TINKERPOP-1467

In release 3.1.3, a recommendation was made to ensure that the threadPoolWorker setting for Gremlin Server was no less than 2 in cases where Gremlin Server was being used with sessions that accept parallel requests. In 3.1.4, that is no longer the case and a size of 1 remains acceptable even in that specific case.

See: TINKERPOP-1350

Gremlin Server has always considered certain binding keys (request parameters) as reserved, but that list has now expanded to be more inclusive all the static enums that are imported to the script engine. It is possible that those using Gremlin Server may have to rename their keys if they somehow successfully were using some of the now reserved terms in previous versions.

See: TINKERPOP-1354

Disabling the timeout for a :remote to Gremlin Server was previously accomplished by setting the timeout to max as in:

where max would set the timeout to be Integer.MAX_VALUE. While this feature is still supported, it has been deprecated in favor of the new configuration option of none, as in:

The use of none completely disables the timeout rather than just setting an arbitrarily high one. Note that it is still possible to get a timeout on a request if the server timeout limits are reached. The console timeout value only refers to how long the console will wait for a response from the server before giving up. By default, the timeout is set to none.

See: TINKERPOP-1267

Past configuration recommendations for the threadPoolWorker setting on Gremlin Server stated this value could be safely set to 1 at the low end. A size of 1 is still valid for most cases, however, if Gremlin Server is being used with sessions that accept parallel requests, then this value should be no less than 2 or else certain scripts (i.e. those that block for an extended period of time) may cause Gremlin Server to lock up the session.

See: TINKERPOP-1350

Calls to SessionedClient.alias() used to throw UnsupportedOperationException and it was therefore not possible to use that capability with a session. That method is now properly implemented and aliasing is allowed.

See: TINKERPOP-1096

The :remote console command provides a way to avoid having to prefix the :> command to scripts when remoting. This mode of console usage can be convenient when working exclusively with a remote like Gremlin Server and there is only a desire to view the returned data and not to actually work with it locally in any way.

See: Reference Documentation - Remote Console

The :remote tinkerpop.server command now allows for a "session" argument to be passed to connect. This argument, tells the remote to configure it with a Gremlin Server session. In this way, the console can act as a window to script exception on the server and behave more like a standard "local" console when it comes to script execution.

See: TINKERPOP-1097

TinkerPop now offers Maven archetypes, which provide example project templates to quickly get started with TinkerPop. The available archetypes are as follows:

See: TINKERPOP-1085, Reference Documentation - Archetypes

When connecting to a session with gremlin-driver, it is now possible to configure the Client instance so as to request that the server manage the transaction for each requests.

Specifying true to the connect() method signifies that the client should make each request as one encapsulated in a transaction. With this configuration of client there is no need to close a transaction manually.

See: TINKERPOP-1039, Reference Documentation - Considering Sessions

The gremlin-driver now has a setting called maxWaitForSessionClose that allows control of how long it will wait for an in-session connection to respond to a close request before it simply times-out and moves on. When that happens, the server will either eventually close the connection via at session expiration or at the time of shutdown.

See: TINKERPOP-1160

The gremlin-core io-package now has a Storage interface. The methods that were available via hdfs (e.g. rm(), ls(), head(), etc.) are now part of Storage. Both HDFS and Spark implement Storage via FileSystemStorage and SparkContextStorage, respectively. SparkContextStorage adds support for interacting with persisted RDDs in the Spark cache.

This update changed a few of the file handling methods. As it stands, these changes only effect manual Gremlin Console usage as HDFS support was previously provided via Groovy meta-programing. Thus, these are not "code-based" breaking changes.