[
https://issues.apache.org/jira/browse/TINKERPOP-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15630039#comment-15630039
]
Kevin Gallardo commented on TINKERPOP-1474:
-------------------------------------------
It sounds important to make the distinction between what is exposed through the
API and what is the data that is actually being sent to clients. On one side
there needs to be a distinction between when the server returns an Element with
its properties and when it does not, based on the type of Traversal (OLAP or
not) and the configuration of the Gremlin server.
However, at least for the Gremlin-Java what is exposed is always the same, the
high level element interface ({{Vertex}}/{{Edge}}), which has properties
methods, and whether what the server sent was a ReferenceElement, or a
DetachedElement, the API will not change for the client. The methods to get
properties will either return the properties if they were sent, or something
empty if they weren't and that will not break users code.
It also sounds important that the GLVs follow the same path in order to achieve
the general rule of thumb [stated in the reference
doc|http://tinkerpop.apache.org/docs/current/reference/#gremlin-variants]:
bq. A strong correspondence between variants ensures that the general Gremlin
reference documentation is applicable to all variants and that users moving
between development languages can easily adopt the Gremlin variant for that
language.
The Graph structure types are already exposed through the python Gremlin
variant, so it sounds like they should be for the other GLVs and in my opinion
we should try to make it as consistent as possible.
> 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: Improvement
> Components: io, language-variant
> 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)
