Andy Tolbert commented on TINKERPOP-1474:

Some questions, just because I think it would be good to clarify these points:

1. [The thread|https://lists.apache.org/thread.html/Z9harwx59p9gj9t] referenced 
in [~spmallette]'s comment seems to indicate the behavior of whether or not the 
properties are present would be configurable in some way:

Just to check, will it be configurable, returning a ReferenceVertex or
the Vertex together with its properties?

The intent is for it be configurable by a new "mime type" so it would end
up configurable per request. Obviously, if you do an OLAP query and all you
get is a ReferenceVertex then your request for a an "upgrade" to a
DetachedVertex (with properties) would go unanswered.

However [~okram] says in this thread:

My personal thinking on this is that if you didn't query for that data, you 
don't get that data. That is, ReferenceXXX by default. I think it is an 
overkill for GLV designers/maintainers to have to now have Vertex 
implementations with multi-/meta-properties, etc. It would be to the point 
where the GLV structure API is nearly as rich as the Java API.... thats alot of 

Given this, is the decision not to include properties on the {{Edge}} and 
{{Vertex}} objects in GLV?

2. The {{Edge}} implemenation in gremlin-python lacks {{inVLabel}} and 
{{outVLabel}}, will these always be present or not?  In any case should it be 
included in the {{Edge}} implementation?

> 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

Reply via email to