[
https://issues.apache.org/jira/browse/TINKERPOP-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695195#comment-17695195
]
ASF GitHub Bot commented on TINKERPOP-2824:
-------------------------------------------
FlorianHockmann commented on code in PR #1843:
URL: https://github.com/apache/tinkerpop/pull/1843#discussion_r1121982613
##########
docs/src/reference/gremlin-applications.asciidoc:
##########
@@ -2250,50 +2250,36 @@ to as "detached elements" and cases where properties
are not included are "refer
With the type of request and detachment model in mind, it is now possible to
discuss how best to consider element
properties in relation to them all in concert.
-By default, Gremlin Server sample configurations utilize
`ReferenceElementStrategy` when creating the out-of-the-box
-`GraphTraversalSource`. As the name suggests, this means that elements will be
detached by reference and will
-therefore not have properties included. The relevant configuration from the
Gremlin Server initialization script looks
-like this:
+By default, Gremlin Server sample configurations return all properties.
+
+To manage properties for each request you can use
<<configuration-steps-with,with()>> configuration option
+`materializeProperties`
[source,groovy]
----
-globals << [g :
traversal().withEmbedded(graph).withStrategies(ReferenceElementStrategy)]
+g.with('materializeProperties', 'tokens').V()
----
-This configuration is global to Gremlin Server and therefore all methods of
connection will always return elements
-without properties. If this strategy is not included, then there are other
considerations to take into account such as
-the connection type (i.e. script or bytecode) and the serializer.
+The `tokens` value for the `materializeProperties` means that need to return
only `id` and `label`. Another option
Review Comment:
```suggestion
The `tokens` value for the `materializeProperties` means that only `id` and
`label` should be returned. Another option
```
##########
docs/src/reference/gremlin-applications.asciidoc:
##########
@@ -2250,50 +2250,36 @@ to as "detached elements" and cases where properties
are not included are "refer
With the type of request and detachment model in mind, it is now possible to
discuss how best to consider element
properties in relation to them all in concert.
-By default, Gremlin Server sample configurations utilize
`ReferenceElementStrategy` when creating the out-of-the-box
-`GraphTraversalSource`. As the name suggests, this means that elements will be
detached by reference and will
-therefore not have properties included. The relevant configuration from the
Gremlin Server initialization script looks
-like this:
+By default, Gremlin Server sample configurations return all properties.
+
+To manage properties for each request you can use
<<configuration-steps-with,with()>> configuration option
+`materializeProperties`
[source,groovy]
----
-globals << [g :
traversal().withEmbedded(graph).withStrategies(ReferenceElementStrategy)]
+g.with('materializeProperties', 'tokens').V()
----
-This configuration is global to Gremlin Server and therefore all methods of
connection will always return elements
-without properties. If this strategy is not included, then there are other
considerations to take into account such as
-the connection type (i.e. script or bytecode) and the serializer.
+The `tokens` value for the `materializeProperties` means that need to return
only `id` and `label`. Another option
+`all` used to indicate that all properties should be returned and is the
default value.
Review Comment:
I think this needs to be:
> Another option, `all`, _can be_ used [...]
##########
docs/src/reference/gremlin-applications.asciidoc:
##########
@@ -2307,10 +2293,8 @@ List<Vertex> results =
g.V().hasLabel("person").elementMap('name').toList();
Both of the above requests return a list of `Map` instances that contain the
`id`, `label` and the "name" property.
-TIP: The example graph configurations pre-packaged with Gremlin Server utilize
`ReferenceElementStrategy`
-which convert all graph elements to references by initializing "g" using
-`withStrategies(ReferenceElementStrategy.instance()`. Consider utilizing
`ReferenceElementStrategy` whenever creating
-a `GraphTraversalSource` in Java to ensure the most portable Gremlin.
+TIP: Consider utilizing `ReferenceElementStrategy` whenever creating a
`GraphTraversalSource` in Java to ensure
+the most portable Gremlin.
NOTE: For those interested, please see
link:https://lists.apache.org/thread.html/e959e85d4f8b3d46d281f2742a6e574c7d27c54bfc52f802f7c04af3%40%3Cdev.tinkerpop.apache.org%3E[this
post]
Review Comment:
I think we should remove this thread here or at least mention that it
discusses the history of this and gives pros/cons, but it doesn't reflect the
current situation any more as properties are now returned by default.
##########
docs/src/reference/gremlin-applications.asciidoc:
##########
@@ -2307,10 +2293,8 @@ List<Vertex> results =
g.V().hasLabel("person").elementMap('name').toList();
Both of the above requests return a list of `Map` instances that contain the
`id`, `label` and the "name" property.
-TIP: The example graph configurations pre-packaged with Gremlin Server utilize
`ReferenceElementStrategy`
-which convert all graph elements to references by initializing "g" using
-`withStrategies(ReferenceElementStrategy.instance()`. Consider utilizing
`ReferenceElementStrategy` whenever creating
-a `GraphTraversalSource` in Java to ensure the most portable Gremlin.
+TIP: Consider utilizing `ReferenceElementStrategy` whenever creating a
`GraphTraversalSource` in Java to ensure
Review Comment:
Is this still a suggestion that we want to make? I'm not sure what is meant
here by "portable Gremlin". Should it be easy to port a traversal to another
GLV? In that case, we can remove the tip now as GLVs can now also deserialize
properties.
Or portable between different graph providers? In that case, it might still
be better to use `ReferenceElementStrategy` maybe, but I'm not sure how
important this consideration is.
##########
docs/src/upgrade/release-3.7.x.asciidoc:
##########
@@ -29,6 +29,28 @@ Please see the
link:https://github.com/apache/tinkerpop/blob/3.7.0/CHANGELOG.asc
=== Upgrading for Users
+==== Properties on Elements
+
+By default properties on Elements are now returned.
+If you don't need to get properties then you can do one of the following ways:
+
+* Configure server to not return properties, update groovy configuration file
with `ReferenceElementStrategy`.
Review Comment:
I think _groovy configuration file_ isn't clear enough for users to
understand which Groovy file they need to edit. Since it's named _Gremlin
Server initialization script_ in the reference docs, I would also use that term
here.
`server` should probably also be renamed to `Gremlin Server`. That way,
users of graphs that don't include Gremlin Server know that this doesn't apply
to them.
##########
docs/src/reference/gremlin-applications.asciidoc:
##########
@@ -2250,50 +2250,36 @@ to as "detached elements" and cases where properties
are not included are "refer
With the type of request and detachment model in mind, it is now possible to
discuss how best to consider element
properties in relation to them all in concert.
-By default, Gremlin Server sample configurations utilize
`ReferenceElementStrategy` when creating the out-of-the-box
-`GraphTraversalSource`. As the name suggests, this means that elements will be
detached by reference and will
-therefore not have properties included. The relevant configuration from the
Gremlin Server initialization script looks
-like this:
+By default, Gremlin Server sample configurations return all properties.
+
+To manage properties for each request you can use
<<configuration-steps-with,with()>> configuration option
+`materializeProperties`
[source,groovy]
----
-globals << [g :
traversal().withEmbedded(graph).withStrategies(ReferenceElementStrategy)]
+g.with('materializeProperties', 'tokens').V()
----
-This configuration is global to Gremlin Server and therefore all methods of
connection will always return elements
-without properties. If this strategy is not included, then there are other
considerations to take into account such as
-the connection type (i.e. script or bytecode) and the serializer.
+The `tokens` value for the `materializeProperties` means that need to return
only `id` and `label`. Another option
+`all` used to indicate that all properties should be returned and is the
default value.
-For script-based requests, users should take care when returning graph
elements. By default, elements will be returned
-as "detached elements" and depending on the serializer being used those
detached elements may or may not have their
-properties carried with them. Gryo and GraphSON serializers will write all
properties in the return payload in this
-case but GraphBinary will not. Therefore, script-based requests that use Gryo
or GraphSON should definitely follow the
-best practice of only returning the data required by the application.
+In some cases it can be inconvenient to load vertices with properties due to
fat data or for compatibility reasons.
+That can be solved by utilize `ReferenceElementStrategy` when creating the
out-of-the-box `GraphTraversalSource`.
+As the name suggests, this means that elements will be detached by reference
and will therefore not have properties
+included. The relevant configuration from the Gremlin Server initialization
script looks like this:
-For bytecode-based requests, graph elements have reference detachment and thus
only return the `id` and `label` of
-the elements. While this approach alleviates a potential performance problem
that the script approach exposes, it is
-still important to follow the practice of being specific about the data that
is required by the requesting application
-as it won't arrive on the client side without that declaration.
-
-Ultimately, the detachment model should have little impact to Gremlin usage if
the best practice of specifying only
-the data required by the application is adhered to. In other words, while
there may be a difference in the contents
-of return values for these traversals:
-
-[source,java]
+[source,groovy]
----
-// properties returned from g.V().hasLabel('person') because this is using the
-// Script API with full detachment
-Cluster cluster = Cluster.open();
-Client client = cluster.connect();
-ResultSet results = client.submit("g.V().hasLabel('person')");
-
-// no properties returned from g.V().hasLabel("person") because this is using
-// Bytecode API with reference detachment
-GraphTraversalSource g =
traversal().withRemote('conf/remote-graph.properties');
-List<Vertex> results = g.V().hasLabel("person").toList();
+globals << [g :
traversal().withEmbedded(graph).withStrategies(ReferenceElementStrategy)]
----
-There is no difference if re-written using the best practice of requesting
only the data the application needs:
+This configuration is global to Gremlin Server and therefore all methods of
connection will always return elements
+without properties. If this strategy is not included, then elements returned
with properties.
Review Comment:
```suggestion
without properties. If this strategy is not included, then elements will be
returned with properties.
```
##########
docs/src/reference/gremlin-applications.asciidoc:
##########
@@ -2250,50 +2250,36 @@ to as "detached elements" and cases where properties
are not included are "refer
With the type of request and detachment model in mind, it is now possible to
discuss how best to consider element
properties in relation to them all in concert.
-By default, Gremlin Server sample configurations utilize
`ReferenceElementStrategy` when creating the out-of-the-box
-`GraphTraversalSource`. As the name suggests, this means that elements will be
detached by reference and will
-therefore not have properties included. The relevant configuration from the
Gremlin Server initialization script looks
-like this:
+By default, Gremlin Server sample configurations return all properties.
+
+To manage properties for each request you can use
<<configuration-steps-with,with()>> configuration option
+`materializeProperties`
[source,groovy]
----
-globals << [g :
traversal().withEmbedded(graph).withStrategies(ReferenceElementStrategy)]
+g.with('materializeProperties', 'tokens').V()
----
-This configuration is global to Gremlin Server and therefore all methods of
connection will always return elements
-without properties. If this strategy is not included, then there are other
considerations to take into account such as
-the connection type (i.e. script or bytecode) and the serializer.
+The `tokens` value for the `materializeProperties` means that need to return
only `id` and `label`. Another option
+`all` used to indicate that all properties should be returned and is the
default value.
-For script-based requests, users should take care when returning graph
elements. By default, elements will be returned
-as "detached elements" and depending on the serializer being used those
detached elements may or may not have their
-properties carried with them. Gryo and GraphSON serializers will write all
properties in the return payload in this
-case but GraphBinary will not. Therefore, script-based requests that use Gryo
or GraphSON should definitely follow the
-best practice of only returning the data required by the application.
+In some cases it can be inconvenient to load vertices with properties due to
fat data or for compatibility reasons.
+That can be solved by utilize `ReferenceElementStrategy` when creating the
out-of-the-box `GraphTraversalSource`.
Review Comment:
```suggestion
That can be solved by utilizing `ReferenceElementStrategy` when creating the
out-of-the-box `GraphTraversalSource`.
```
> Properties on Elements
> ----------------------
>
> Key: TINKERPOP-2824
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2824
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet, driver, go, javascript, process, python
> Affects Versions: 3.5.4
> Reporter: Valentyn Kahamlyk
> Assignee: Valentyn Kahamlyk
> Priority: Major
>
> Problem: When a user writes `g.V()` they get back a Vertex object. The
> problem is that depending on the execution context of the traversal, the
> result could be quite different, with or without properties.
> Solution: Implement new finalization strategy DetachStrategy(detachMode,
> properties) where mode is one of ALL, NONE or CUSTOM. `properties` is list of
> properties name, are taken into account only for CUSTOM mode.
> Discussion thread in dev list: [Proposal to handle properties on response
> Elements-Apache Mail
> Archives|https://lists.apache.org/thread/l8rw7ydj7kym8vhtwk50nhbp45ng9986]
> Stephen's thread in dev list: [The Issue of Detachment-Apache Mail
> Archives|https://lists.apache.org/thread/xltcon4zxnwq4fyw2r2126syyrqm8spy]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
