[ 
https://issues.apache.org/jira/browse/TINKERPOP-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15685033#comment-15685033
 ] 

ASF GitHub Bot commented on TINKERPOP-1520:
-------------------------------------------

Github user okram commented on a diff in the pull request:

    https://github.com/apache/tinkerpop/pull/499#discussion_r89010296
  
    --- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java
 ---
    @@ -459,9 +486,33 @@ public PropertyJacksonDeserializer() {
     
             @Override
             public Property createObject(final Map<String, Object> propData) {
    -            return new DetachedProperty(
    -                    (String) propData.get(GraphSONTokens.KEY),
    -                    propData.get(GraphSONTokens.VALUE));
    +            final Object element = propData.get(GraphSONTokens.ELEMENT);
    +            return element instanceof Element ? // graphson-non-embedded 
is treated differently, but since this is a hard coded embedding...
    +                    new DetachedProperty<>((String) 
propData.get(GraphSONTokens.KEY), propData.get(GraphSONTokens.VALUE), (Element) 
element) :
    +                    new DetachedProperty<>((String) 
propData.get(GraphSONTokens.KEY), propData.get(GraphSONTokens.VALUE));
    +        }
    +    }
    +
    +    static class VertexPropertyJacksonDeserializer extends 
AbstractObjectDeserializer<VertexProperty> {
    +
    +        protected VertexPropertyJacksonDeserializer() {
    +            super(VertexProperty.class);
    +        }
    +
    +        @Override
    +        public VertexProperty createObject(final Map<String, Object> 
propData) {
    +            return propData.containsKey(GraphSONTokens.VERTEX) ?
    +                    new DetachedVertexProperty<>(
    +                            propData.get(GraphSONTokens.ID),
    +                            (String) propData.get(GraphSONTokens.LABEL),
    +                            propData.get(GraphSONTokens.VALUE), 
(Map<String, Object>) propData.get(GraphSONTokens.PROPERTIES),
    +                            new 
DetachedVertex(propData.get(GraphSONTokens.VERTEX), Vertex.DEFAULT_LABEL, 
null)) :
    --- End diff --
    
    I don't quite follow what you are saying, but if you have a cool idea with 
"context awareness," by all means, push a patch to this branch.
    
    Here is the thing about being able to attach an element back to the main 
graph.
    
    * `Vertex`: All you need is the vertex ID.
    * `Edge`: Edge ID (but for most dbs, outV id and edge label too)
    * `VertexProperty`: vertex property ID, vertex ID (but for optimization in 
most dbs, label too).
    * `Property`: key/value, element id. Given that properties are ONLY on 
vertex properties and edges, then you need the requisite information about the 
element for attachment.


> Difference between 'has' step generated graphson2.0 in java and python glv 
> implementation
> -----------------------------------------------------------------------------------------
>
>                 Key: TINKERPOP-1520
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1520
>             Project: TinkerPop
>          Issue Type: Bug
>          Components: language-variant
>    Affects Versions: 3.2.3
>            Reporter: Andy Tolbert
>
> Noticed that between the java and python implementations, the graphson2.0 
> payload generated for a {{has}} step is different.  i.e. for the given 
> traversal:
> {{g.E().has("weight", 0.2)}}
> The java implementation produces the following graphson:
> {code:javascript}
> {"@type":"g:Bytecode","@value":{"step":[["E"],["has","weight",{"@type":"g:P","@value":{"predicate":"eq","value":{"@type":"g:Double","@value":0.2}}}]]}}
> {code}
> where the python implementation produces the following:
> {code:javascript}
>  {"@type":"g:Bytecode","@value":{"step":[["E"],["has","weight",0.2]]}}
> {code}
> In the java case, a {{g\:P}} typed (predicate) value is provided, where in 
> the python case that isn't the case.
> I'm assuming the java one is correct (primarily since the graph backend seems 
> to like it and return the expected result).   Should GLV implementations 
> behave this way?  I noticed that {{GraphTraversal#has(String propertyKey, 
> Object value)}} in the java TinkerPop api wraps the value in a predicate 
> ({{P.eq}}) under the covers 
> ([link|https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java#L922])
>  so maybe implementors will need to do the same ([python 
> link|https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/process/graph_traversal.py#L193])?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to