You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "Andy Tolbert (JIRA)" <ji...@apache.org> on 2016/10/18 20:32:58 UTC
[jira] [Comment Edited] (TINKERPOP-1474) API Alignment Between Java
Gremlin Graph Structure and GLVs
[ https://issues.apache.org/jira/browse/TINKERPOP-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15586586#comment-15586586 ]
Andy Tolbert edited comment on TINKERPOP-1474 at 10/18/16 8:32 PM:
-------------------------------------------------------------------
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:
{quote}
https://lists.apache.org/thread.html/5a04893d04b6b9f8f33c163f471bcdee18cc8e23d59b02a8f591a47b@1463679213@%3Cdev.tinkerpop.apache.org%3E
Just to check, will it be configurable, returning a ReferenceVertex or
the Vertex together with its properties?
{quote}
{quote}
https://lists.apache.org/thread.html/17ad6d1a9583ef9080be6b8b10b83cc60a971236b4d42f957411af99@1463679388@%3Cdev.tinkerpop.apache.org%3E
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.
{quote}
However [~okram] says in this thread:
{quote}
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 code.
{quote}
Given this, is the decision to not 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?
was (Author: andrew.tolbert):
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:
{quote}
https://lists.apache.org/thread.html/5a04893d04b6b9f8f33c163f471bcdee18cc8e23d59b02a8f591a47b@1463679213@%3Cdev.tinkerpop.apache.org%3E
Just to check, will it be configurable, returning a ReferenceVertex or
the Vertex together with its properties?
{quote}
{quote}
https://lists.apache.org/thread.html/17ad6d1a9583ef9080be6b8b10b83cc60a971236b4d42f957411af99@1463679388@%3Cdev.tinkerpop.apache.org%3E
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.
{quote}
However [~okram] says in this thread:
{quote}
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 code.
{quote}
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
(v6.3.4#6332)