[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

["stephen mallette (JIRA)" <ji...@apache.org>]

    [ 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)