This is an automated email from the ASF dual-hosted git repository.
spmallette pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tinkerpop.git
The following commit(s) were added to refs/heads/master by this push:
new 201c31680f Make the feature support-check example in The Graph
self-contained
201c31680f is described below
commit 201c31680f5e4b45473920b20585402ee47515b5
Author: Stephen Mallette <[email protected]>
AuthorDate: Thu Sep 10 19:07:21 2026 +0000
Make the feature support-check example in The Graph self-contained
The support-check example referenced a traversal source g that was only
defined in an earlier, separate code block. It ran without error solely
because TinkerGraph does not support transactions, so the ternary's true
branch was never evaluated. A reader adapting this pattern for a
transactional graph would have hit an error on the undefined g. Define g
from graph within the block so the example stands on its own. Also add a
short note describing how the features() output is grouped, so a reader
can orient in the long list of boolean flags.
Assisted-by: Kiro:claude-opus-4.8
---
docs/src/reference/the-graph.asciidoc | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/docs/src/reference/the-graph.asciidoc
b/docs/src/reference/the-graph.asciidoc
index 2f671883f6..9814abe739 100644
--- a/docs/src/reference/the-graph.asciidoc
+++ b/docs/src/reference/the-graph.asciidoc
@@ -76,10 +76,18 @@ graph = TinkerGraph.open()
graph.features()
----
-A common pattern for using features is to check their support prior to
performing an operation:
+The printed output groups the supported capabilities by the element they
describe: graph features (which
+include a nested set of variable features), vertex features (with their vertex
property features), and edge
+features (with their edge property features). Each group lists the individual
capabilities of that element
+type as boolean flags, where a value of `true` indicates that the `Graph`
supports the associated operation.
+
+A common pattern for using features is to check their support prior to
performing an operation. The example
+below creates a traversal source `g` from the `graph` and guards a transaction
commit behind the relevant
+feature check, so that the commit is only attempted when the `Graph` actually
supports transactions:
[gremlin-groovy]
----
+g = traversal().with(graph);[]
graph.features().graph().supportsTransactions()
graph.features().graph().supportsTransactions() ? g.tx().commit() : "no tx"
----