[
https://issues.apache.org/jira/browse/TINKERPOP-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15525889#comment-15525889
]
stephen mallette commented on TINKERPOP-1474:
---------------------------------------------
The return of {{DetachedVertex}} was a historical decision going back to
Rexster in TinkerPop 2.x (which returned properties first for REST and then
also for its binary protocol). We basically continued in that way for TinkerPop
3.x. In the last six to twelve months though, we've seen need to change that
such that we don't return properties anymore for requests that return Graph
elements (vertices/edges). There area number of reasons for that, but two
primary ones are:
1. Consistency with OLAP which returns {{Reference*} elements
2. Vertices with multi-properties which could return millions of properties per
vertex potentially would be expensive to gather/serialize.
So - ultimately, you wouldn't {{g.V()}} to return properties anymore than you
would want "select * from table" to return them. You'd specifically query the
properties that you wanted.
We are currently stuck in a transitional period for going to use {{Reference*}}
elements across the board. To do so immediately would break lots of users who
are depending on properties to be present. This was discussed here:
https://lists.apache.org/thread.html/Z9harwx59p9gj9t
Note that consensus was not reached on not returning properties by default (a
decision delayed for later), though, given the two reasons for doing so listed
above, I'm not sure how we could not go that direction. We took a step towards
implementing "returning {{Reference*}} on TINKERPOP-1308, but only for Gryo.
I think we need to look to make the change on this for 3.3.0 when we will allow
"larger" breaking changes. For users this would mean that they would have to
manually switch to a different serializer as the default would change to return
the {{Reference*}} instead of {{Detached*}}.
I also think this work needs to be done at a serializer-level, because simply
implementing a different "detach" mechanism in {{HaltedTraverserStrategy}}
won't properly detach an {{Element}} unless the {{Traverser}} contains the
{{Element}} - if it were {{List<Element>}} we would still get properties. If
this logic were part of the serializer then the entire object tree of a
{{Traverser}} is considered and detachment would occur properly. I also think
doing it at a serializer level, yields greater flexibility as the client can
choose via mime-type which behavior (properties or no properties) they want at
the time of a request.
For completeness of the thinking, we had once wondered if the Gremlin language
itself couldn't be expanded to allow for something like:
{code}
g.V().with('name')
{code}
In this way, the user could be explicit about the properties to populate to a
{{Vertex}}. I think we'd envisioned that something like {{with('name')}} would
trigger the detachment at that step and from that point forward, users could
only interact with the {{Vertex}} based on those properties requested. I don't
remember why we said that couldn't work - [~okram] do you happen to remember?
[~dmill] you were the only other person who contributed on that thread i
referenced above - any new thoughts on this?
[~davebshow] this would affect gremlin-python, goblin, etc. - concerns?
> API Alignment Between Java Gremlin Graph Structure and GLVs
> -----------------------------------------------------------
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
> Issue Type: Bug
> Components: io
> Affects Versions: 3.2.2
> Reporter: Adam Holmberg
>
> The current Java GraphSON implementation and that in the Python GLV leave
> some question about what *should* be returned from a simple traversal like
> `g.V()`.
> The java implementation presently assumes that properties could be present
> and returns a DetachedVertex:
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more
> reminiscent of a ReferenceVertex:
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align
> these APIs?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
