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

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_r88914949
  
    --- Diff: 
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java
 ---
    @@ -175,8 +177,30 @@ public PropertyJacksonSerializer() {
             public void serialize(final Property property, final JsonGenerator 
jsonGenerator, final SerializerProvider serializerProvider)
                     throws IOException {
                 jsonGenerator.writeStartObject();
    -            jsonGenerator.writeObjectField(GraphSONTokens.KEY, 
property.key());
    +            jsonGenerator.writeStringField(GraphSONTokens.KEY, 
property.key());
                 jsonGenerator.writeObjectField(GraphSONTokens.VALUE, 
property.value());
    +            if (property.element() instanceof VertexProperty) {
    +                VertexProperty vertexProperty = (VertexProperty) 
property.element();
    +                
jsonGenerator.writeObjectFieldStart(GraphSONTokens.ELEMENT);
    +                jsonGenerator.writeStringField(GraphSONTokens.VALUETYPE, 
"g:VertexProperty");
    +                
jsonGenerator.writeObjectFieldStart(GraphSONTokens.VALUEPROP);
    +                jsonGenerator.writeObjectField(GraphSONTokens.ID, 
vertexProperty.id());
    +                jsonGenerator.writeStringField(GraphSONTokens.LABEL, 
vertexProperty.label());
    +                jsonGenerator.writeObjectField(GraphSONTokens.VERTEX, 
vertexProperty.element().id());
    +                jsonGenerator.writeEndObject();
    +                jsonGenerator.writeEndObject();
    +            } else if (property.element() instanceof Edge) {
    +                Edge edge = (Edge) property.element();
    +                
jsonGenerator.writeObjectFieldStart(GraphSONTokens.ELEMENT);
    +                jsonGenerator.writeStringField(GraphSONTokens.VALUETYPE, 
"g:Edge");
    --- End diff --
    
    You can't always expect `outVLabel` and `inVLabel` to exist. Think about 
`ReferenceEdge`. It would be too expensive to always include such information. 
The most important think about the serialization is "can it be attached?" The 
way GraphSON 2.0 was designed, this was not the case. How do you attach a 
property? an vertex property? Finally, given the attach requirements of an 
edge, you have the problem of:
    
    property -> edge -> vertex (which vertex -- in or out?) ...  
    
    The amount of data required to attach a property would be pretty nasty. 
Hence, the "reference" serialization is smaller.


> 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