Cole-Greer commented on code in PR #3384:
URL: https://github.com/apache/tinkerpop/pull/3384#discussion_r3132569188
##########
docs/src/reference/gremlin-applications.asciidoc:
##########
@@ -469,31 +469,93 @@ That file tells Gremlin Server many things such as:
* Thread pool sizes
* Where to report metrics gathered by the server
* The serializers to make available
-* The Gremlin `ScriptEngine` instances to expose and external dependencies to
inject into them
* `Graph` instances to expose
+* `TraversalSource` bindings (auto-created or explicitly declared)
+* `LifeCycleHook` implementations for startup/shutdown logic
The log messages that printed above show a number of things, but most
importantly, there is a `Graph` instance named
`graph` that is exposed in Gremlin Server. This graph is an in-memory
TinkerGraph and was empty at the start of the
-server. An initialization script at `scripts/generate-modern.groovy` was
executed during startup. Its contents are
-as follows:
+server. A `TinkerFactoryDataLoader` lifecycle hook loaded the "modern"
dataset into it during startup, and a
+`TraversalSource` named `g` was auto-created from the `graph` entry.
-[source,groovy]
+[[server-auto-traversal-sources]]
+==== Auto-Created TraversalSources
+
+When Gremlin Server starts, it automatically creates a `TraversalSource` for
each graph in the `graphs` configuration
+that does not have an explicit entry in the `traversalSources` section. The
naming convention is:
+
+* A graph named `graph` gets a `TraversalSource` named `g`
+* All other graphs get `g_<name>` (e.g. a graph named `modern` gets `g_modern`)
+
+This means a minimal configuration like the following is fully functional:
+
+[source,yaml]
+----
+graphs: {
+ graph: conf/tinkergraph-empty.properties}
+----
+
+[[server-traversal-sources]]
+==== Declarative TraversalSources
+
+For more control, the `traversalSources` YAML section allows explicit
`TraversalSource` creation with optional
+strategy configuration via a Gremlin expression:
+
+[source,yaml]
+----
+traversalSources: {
+ g: {graph: graph},
+ gReadOnly: {graph: graph, gremlinExpression:
"g.withStrategies(ReadOnlyStrategy)", language: "gremlin-lang"}}
+----
+
+Each entry supports:
+
+* `graph` (required) — references a key in the `graphs` section
+* `gremlinExpression` (optional) — a Gremlin expression evaluated with a base
traversal source bound as `g`; the
+ result becomes the final `TraversalSource`
+* `language` (optional) — which script engine to use for expression
evaluation; defaults to `gremlin-lang`, or the
+ sole configured engine if only one is present
+
+Graphs with explicit `traversalSources` entries are excluded from
auto-creation.
+
+[[server-lifecycle-hooks]]
+==== LifeCycleHooks
Review Comment:
I had a similar thought when working on the `TinkerFactoryDataLoader` hook
for this PR. I think it would be nice to elevate the TinkerFactory
`generate<Dataset>()` methods from `tinkergraph-gremlin` to `gremlin-core`,
along with a refactor to work with any arbitrary `Graph`. All of the small
graphs are already simply based on the Structure API. There's no reason we
couldn't make those directly available to arbitrary graphs. For airRoutes and
grateful, I'd also like to make them more generally available (perhaps
restricted to graphs which support reading gryo via the io() step, or perhaps
via a long gremlin load script).
Taking this a step further and providing a prepackaged data loader where
users just need to provide a path in the config is a nice convenience. I think
with the Java lifecycle hooks, we can offer a lot more prebuilt configurable
lifecycle hooks, instead of asking providers to write all their own scripts.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
