Hi,

I am updating my original answer based on the various comments.

A graph traversal is composed of an ordered list of steps, separated by dots (.).

In DSE Graph 6.8 there is a hard limit on the "length" of the traversal, i.e the number of steps in the traversal. It is limited to 90. This is a hard limit and it is not configurable.

If you were to string several addV() steps together like in your example, you would run into this limit already with 31 vertices.

I am pasting the resulting error below:

gremlin> g.addV('person').property('person_id', 'person0').as('0').addV('person').property('person_id', 'person1').as('1').
.
.
.
.addV('person').property('person_id', 'person29').as('29').addV('person').property('person_id', 'person30').as('30')
The submitted traversal exceeded the maximum length allowed of '90'. Please split it into multiple smaller traversals.

You will still run into this limit when using Fluent API, albeit a bit later. When sending the traversal through fluent API, the traversal is converted to bytecode first, and the steps are then apparently counted differently than when going through script API (or Gremlin console). Step modulators such as property() and as() steps seem to not get counted as steps in this case. However, the addV() or addE() steps are contribute to the count, and you will still run into the max traversal length limit of 90 if updating close to 90 elements.

The steps counted from the bytecode traversal seem to include a couple of extra steps, so we don't get quite to the full 90 elements. I have tested this and managed to update 87 vertices before hitting the limit.

I would advise that you test where exactly the limit lies with your specific update query, but it will most certainly be below 90 updates.

For some additional information about the fluent API, see this blog.

---

The following approach could be used for updating more graph elements with one Gremlin traversal.

This is heavily based on the examples from this page: https://tinkerpop.apache.org/docs/current/recipes/#long-traversals

Create your data first (here for 100 vertices):

persons = (1..100).collect {["person_id": "person_${it}", "name": "name_${it}", "age": it + 20]}

Inject the data into the traversal and process them as a side effect. This now inserts 100 vertices.

g.inject(persons).sideEffect(
   unfold().
   addV("person").property("person_id", select("person_id")).property("name", 
   select("name")).property("age", select("age"))
).iterate()

The number of operations per traversal is limited, but configurable, as the following error shows:

gremlin> g.inject(persons).sideEffect(unfold().addV("person").property("person_id", select("person_id")).property("name", select("name")).property("age", select("age"))).iterate()
Maximum number of operations (10000) exceeded.
Possible solutions to this are:
 - break your traversal into chunks
 - up the maximum number of mutations by adding g.with("max-mutations", N) at the beginning of your traversal

However, packing these updates into a single traversal is no guarantee for all-or-nothing updates. The above example scaled up to 10000 inserts failed due to timeouts, resulting in dropped mutations and therefore in a partial update. Breaking the inserts into several traversals seems to be a better option in this case.

persons = (1..100).collect {["person_id": "person_${it}", "name": "name_${it}", "age": it + 20]}

g.inject(persons).sideEffect(
   unfold().
   addV("person").property("person_id", select("person_id")).property("name", 
   select("name")).property("age", select("age"))
).iterate()

gremlin> g.inject(persons).sideEffect(unfold().addV("person").property("person_id", select("person_id")).property("name", select("name")).property("age", select("age"))).iterate()
Maximum number of operations (10000) exceeded.
Possible solutions to this are:
 - break your traversal into chunks
 - up the maximum number of mutations by adding g.with("max-mutations", N) at the beginning of your traversal