[ 
https://issues.apache.org/jira/browse/TINKERPOP-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631033#comment-17631033
 ] 

ASF GitHub Bot commented on TINKERPOP-2824:
-------------------------------------------

spmallette commented on code in PR #1843:
URL: https://github.com/apache/tinkerpop/pull/1843#discussion_r1017858669


##########
docs/src/reference/the-traversal.asciidoc:
##########
@@ -4916,6 +4916,28 @@ g.V().hasLabel('person'). <1>
 <8> `PathRetractionStrategy` will remove paths from the traversers and 
increase the likelihood of bulking as path data is not required after 
`select('b')`.
 <9> `AdjacentToIncidentStrategy` will turn `out()` into `outE()` to increase 
data access locality.
 
+=== DetachStrategy
+
+`DetachStrategy` manages the fields that will be included in the result. The 
strategy adds a step to the end of the traversal 
+and does not affect the previous steps.
+There are 3 options for detachMode: `ALL` for all properties, `NONE` for no 
properties, `CUSTOM` for a specific list of properties.
+`id` and `label` always included in response.
+Same for Vertexes and Edges.
+
+WARNING: by default Gremlin Server configured to use 
`ReferenceElementStrategy` which removes all properties.

Review Comment:
   > I think ReferenceElementStrategy may be deprecated in 3.7.
   There are some small differences between ReferenceElement and 
DetachedElement that need to be aligned before.
   
   I'm not sure that `ReferenceElement` can be replaced by `DetachedElement` 
for all use cases. The original point of `ReferenceElement` is to avoid the the 
memory costs of even having an empty `Map<String, List<Property>> properties` 
declaration at all for OLAP use cases. `ReferenceElement` is meant to be as 
light as possible. If it could be proven that `DetachedElement` could have that 
same memory footprint I suppose the entire `ReferenceElement` infrastructure 
could be deprecated. 
   
   As far as `ReferenceElementStrategy` goes.......I think that can be 
deprecated as part of this because it is not use in OLAP iirc. It is only used 
for the case `DetachStrategy` is and is behaviorally identical for practical 
purposes.
   
   > I consider default may be DetachStrategy configured to skip properties. I 
think users who want to get properties can remove the strategy from server 
startup or use it from the client when needed. Most current users don't expect 
to get properties and it doesn't make sense to load the server and network.
   
   i'd agree. so the only real change users will get is that they will now get 
a `DetachedElement` rather than a `ReferenceElement` and hopefully they haven't 
been coding to the implementation and will not notice the difference as they 
would be working with the interface of `Element`.  The upgrade documentation 
will need to be sure to include this notice.





> 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
>             Fix For: 3.7.0
>
>
> 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)

Reply via email to